Project

General

Profile

Bug #7412

PresortQuery ORDER BY has to many clauses

Added by Alexandru Lungu about 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Ștefan Roman
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

presortquery.p Magnifier (2.47 KB) Dănuț Filimon, 06/14/2023 04:51 AM

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.pMagnifier 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 be null initially
    • only if you intend to add something to the set, consider instantiating it
  • 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, compute crit and add to the list of sort criteria.
  • Fine tuning:
    • do for (i ...) class loop instead of for-each (it is faster as we avoid instantiating an Iterator under the hood).

#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.

#17 Updated by Greg Shah 11 months ago

  • Status changed from Test to Closed

Also available in: Atom PDF