Bug #7412
PresortQuery ORDER BY has to many clauses
100%
History
#1 Updated by Alexandru Lungu about 1 year ago
I have the following SQL generated in H2 for a PresortQuery
:
select tt.* from tt where tt._multiplex = ? order by tt._multiplex asc, tt.recid asc, tt.recid asc
The ORDER BY has two recid
clauses. This may affect the H2 planner, as the order by doesn't match the index. In fact, I tested H2 and I get index sorted
for a correct ORDER BY and tableScan
for the example above.
I think we can handle this easier from FWD than from FWD-H2. I have an implementation for "incremental indexed sorting" in H2 that could handle this, but the overhead seemed too big for other queries back then.
Please note that such example occurred to me when using PresortQuery
over a table with no indexes (except the implicit [multiplex, recid]
). For AdaptiveQuery
, it looks right.
#2 Updated by Alexandru Lungu about 1 year ago
- Status changed from New to WIP
- Assignee set to Dănuț Filimon
Danut, please investigate. The change should go to 7026e when ready.
#3 Updated by Alexandru Lungu about 1 year ago
Danut, please prioritize this if you think it can be fixed by the end of this week. From my POV, there shouldn't be any obvious impediments. Feel free to update on your progress here.
#4 Updated by Alexandru Lungu about 1 year ago
- Assignee changed from Dănuț Filimon to Ștefan Roman
#5 Updated by Dănuț Filimon about 1 year ago
- Assignee changed from Ștefan Roman to Dănuț Filimon
- File presortquery.p
added
The clause is added firstly at initialization which is correct since there can be multiple clauses that may need to be constructed from the sort
in PresortQuery.buildSortCriteria
, but the same clause is built for each component of the query in PresortQuery.assembleOrderByClause
.
I attached the test case that I used, feel free to use and modify it as needed.
#6 Updated by Dănuț Filimon about 1 year ago
- Assignee changed from Dănuț Filimon to Ștefan Roman
#7 Updated by Ștefan Roman about 1 year ago
Committed to 7026e, revision 14603.
#8 Updated by Alexandru Lungu about 1 year ago
Review of 7026e, revision 14603
- We can go the extra mile here for performance sake
- let
recIdsSet
benull
initially - only if you intend to add something to the set, consider instantiating it
- let
- Delay
crit
computation as much as possible- fill the set only with the dmo alias to avoid computing the whole
<alias>.<field> asc
. The set should have only<alias>
- if the size of the set is equal to the number of components, you can skip the whole
for
loop - otherwise, only check if the set has the
buffer.getDMOAlias()
. If it doesn't, computecrit
and add to the list of sort criteria.
- fill the set only with the dmo alias to avoid computing the whole
- Fine tuning:
- do
for (i ...)
class loop instead of for-each (it is faster as we avoid instantiating anIterator
under the hood).
- do
#9 Updated by Alexandru Lungu about 1 year ago
- % Done changed from 0 to 80
#10 Updated by Ștefan Roman about 1 year ago
I added all the changes.
Committed to 7026e revision 14604.
#11 Updated by Alexandru Lungu about 1 year ago
This can be optimized a bit further:
- Avoid using .size() in for - precompute it in another variable.
- Use
SortCriterion.isPrimaryKey
to detect if this is a primary key faster (instead of retrieving name and doing equals).
#12 Updated by Ștefan Roman about 1 year ago
Done, I committed the changes on 7026e, revision 14605.
#13 Updated by Alexandru Lungu about 1 year ago
- % Done changed from 80 to 100
- Status changed from WIP to Review
Stefan, please add a history entry to src/com/goldencode/p2j/persist/PresortQuery.java
regarding your changes. Don't rewrite the # number - just the userid, date and description.
#14 Updated by Ștefan Roman about 1 year ago
I added it, committed to 7026e, revision 14647.
#15 Updated by Alexandru Lungu 12 months ago
- Status changed from Review to Test
7026e reached trunk as rev. 14638.
This can be closed now.
#16 Updated by Alexandru Lungu 11 months ago
This can be closed.