|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Relate
|
|
This issue relate to:
|
|
CORE-4428
Make optimizer to consider MIN/MAX optimization when making decision about join order
|
|
|
|
|
|
This issue is related to:
|
|
|
|
|
|
|
|
| QA Status: |
Done successfully
|
| Test Details: |
in 2.1 and 2.5: PLAN SORT (JOIN (M NATURAL, D INDEX (THORSES_COLOR_ID))) -- doesn`t see 'rows 1'.
in 3.0 plan should CHANGE and take in account 'rows N' limit.
in 2.1 and 2.5: PLAN SORT (JOIN (M NATURAL, D INDEX (THORSES_COLOR_ID))) -- doesn`t see 'rows 1'.
in 3.0 plan should CHANGE and take in account 'rows N' limit.
|
|
When only limited number of rows is requested (using FIRST/ROW) from ordered set, fetching records in index order is preferable to sort. Optimizer should prefer join order that will allow using navigational index.
Just an idea: Introducing fixed cardinality of result set forced by FIRST/ROWS into calculations may solve this issue naturally.
Original description:
i have problem with Firebird 1.5.4 and Select First
i do something like that
select
FIRST 1
*
FROM
HIST_DB H
INNER JOIN ADRESY_DB A ON A.ID=H.ID_OBJ
ORDER BY H.ID ASC
PLAN SORT (JOIN (A NATURAL,H INDEX (FK_HIST_DB__ID_OBJ)))
and HIST_DB have 1 000 000 records
ADRESY_DB have 100 000 records
this query run in 10 minutes!
plan should be like this
PLAN JOIN (H ORDER PK_HIST_DB__ID,A INDEX (PK_ADRESY_DB__ID))
|
|
Description
|
When only limited number of rows is requested (using FIRST/ROW) from ordered set, fetching records in index order is preferable to sort. Optimizer should prefer join order that will allow using navigational index.
Just an idea: Introducing fixed cardinality of result set forced by FIRST/ROWS into calculations may solve this issue naturally.
Original description:
i have problem with Firebird 1.5.4 and Select First
i do something like that
select
FIRST 1
*
FROM
HIST_DB H
INNER JOIN ADRESY_DB A ON A.ID=H.ID_OBJ
ORDER BY H.ID ASC
PLAN SORT (JOIN (A NATURAL,H INDEX (FK_HIST_DB__ID_OBJ)))
and HIST_DB have 1 000 000 records
ADRESY_DB have 100 000 records
this query run in 10 minutes!
plan should be like this
PLAN JOIN (H ORDER PK_HIST_DB__ID,A INDEX (PK_ADRESY_DB__ID))
|
Show » |
| There are no subversion log entries for this issue yet.
|
|
Improvement
Resolved
Minor
