Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issue with some queries on Linux 32 bits [CORE1203] #1628

Closed
firebird-issue-importer opened this issue Apr 11, 2007 · 10 comments
Closed

Comments

@firebird-issue-importer

Submitted by: @kattunga

Attachments:
FBTEST.zip

Some queries takes 100% more time in FB2.0.1 Linux 32 bits compared with FB1.5.x.
There is more information in developer forum under "PLAN Optimization problem in FB 2.0.1" thread.
A test database with query example is attached

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 11, 2007

Modified by: @kattunga

Attachment: FBTEST.zip [ 10330 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 11, 2007

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 11, 2007

Modified by: @kattunga

description: Some queries takes 100% more time in FB2.0.1 Linux 32 bits compared with FB1.5.x.
There is more information in developer forum under "PLAN Optimization problem in FB 2.0.1" thread.
A test database with and example could be request at mailto:c_pradelli@yahoo.com.

=>

Some queries takes 100% more time in FB2.0.1 Linux 32 bits compared with FB1.5.x.
There is more information in developer forum under "PLAN Optimization problem in FB 2.0.1" thread.
A test database is attached

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 11, 2007

Modified by: @kattunga

description: Some queries takes 100% more time in FB2.0.1 Linux 32 bits compared with FB1.5.x.
There is more information in developer forum under "PLAN Optimization problem in FB 2.0.1" thread.
A test database is attached

=>

Some queries takes 100% more time in FB2.0.1 Linux 32 bits compared with FB1.5.x.
There is more information in developer forum under "PLAN Optimization problem in FB 2.0.1" thread.
A test database with query example is attached

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 10, 2007

Commented by: @AlexPeshkoff

Christian!
After backporting of Vlad's speed fix for sparse bitmaps, I see 15% difference between fb 1.5 and 2.0 (gcc 3.4.6, amd64, both in 32-bit mode optimized for this CPU). But fb2.0 consumes 25-30 times less memory compared with 1.5. This all is predictable - used in 2.0 Btree instead of hash table to represent sparse bitmap works in some cases a bit slower, but always requires _much_ less memory.

I suggest to close this issue as fixed in 2.0.2.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 21, 2007

Commented by: @AlexPeshkoff

See my previous comments on an issue, please.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 21, 2007

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.0.2 [ 10130 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 16, 2007

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

Workflow: jira [ 11752 ] => Firebird [ 14718 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants