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

Estimate the actual record compression ratio in the optimizer [CORE3295] #3663

Closed
firebird-automations opened this issue Dec 28, 2010 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @dyemanov

Currently, when the table cardinality (number of records) gets estimated, all records are considered to be compressed twice in size (hardcoded compression ratio of 0.5). It would be better to have some estimation (even rough) of the actual compression ratio, because in practice it can differ much from the expected value. This becomes more important starting with versions 2.1.4 and 2.5.0 that have the join cost more depending on the proper cardinality estimations than in prior versions.

Commits: 11297a0 b5dc562 f19f33a d81d678

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

security: Developers [ 10012 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

Fix Version: 2.1.4 [ 10361 ]

Fix Version: 2.5.1 [ 10333 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0.3 [ 10810 ]

Fix Version: 4.0 Beta 1 [ 10750 ]

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

No branches or pull requests

2 participants