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
Efficient table scans for DBKEY-based range conditions [CORE6278] #6520
Comments
Commented by: @dyemanov Some examples of how it could be reported in the detailed query plans: select count(*) from q; Select Expression select count(*) from q where rdb$db_key > x'8700000001000000'; Select Expression select count(*) from q where rdb$db_key <= x'8700000001000000'; Select Expression select count(*) from q where rdb$db_key >= x'8700000001000000' and rdb$db_key <= x'8700000005000000'; Select Expression select count(*) from q where rdb$db_key between x'8700000001000000' and x'8700000005000000'; Select Expression |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Beta 2 [ 10888 ] |
Commented by: @livius2 Sorry for off topic |
Commented by: @dyemanov Parallel table scans, for example. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Done successfully |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @dyemanov
Currently queries with conditions like (RDB$DB_KEY = :param) use a very fast lookup of single record based on its number decoded from DBKEY. But if some range condition is used (e.g. RDB$DB_KEY > :param), then a full table scan is performed. However, if the lower/upper limits for the retrieval are provided, then a "partial" table scan could be performed instead.
The logical record number space is sequential and the full table scan just iterates starting with the zero number until the last record is seen. It can be modified to start with the given "lowest" record number and stop as soon as the last fetched record number is bigger than the given "upper" record number.
Commits: 3ce4605
The text was updated successfully, but these errors were encountered: