Project

Profile

Help

Forums » Help »

Query significantly slower in Saxon 8.5

Added by Anonymous over 19 years ago

Legacy ID: #3279547 Legacy Poster: marcvc (marcvc)

Michael, The following query: for $p in doc("PART.xml")//PART[P_PARTKEY < 20] for $ps in doc("PARTSUPP.xml")//PARTSUPP where $ps/PS_AVAILQTY = max(doc("PARTSUPP.xml")//PARTSUPP[PS_PARTKEY < $p/P_PARTKEY]/PS_AVAILQTY) order by $ps/PS_PARTKEY, $ps/PS_SUPPKEY, $p/P_PARTKEY return <match>{$p}{$ps}</match> In Saxon 8.5 it evaluates significantly slower compared to 8.4. Obviously this depends on the actual documents being queried, but for a given set in our environment approximately 600 ms compared to nearly 70 seconds. If helpful, I can provide you a PART and PARTSUPP document. Thanks, Marc


Replies (3)

Please register to reply

RE: Query significantly slower in Saxon 8.5 - Added by Anonymous over 19 years ago

Legacy ID: #3280545 Legacy Poster: Michael Kay (mhkay)

Could you send me the source documents please? I can't see anything in the query execution plans produced by 8.4 and 8.5 that would obviously account for this difference in performance: both appear to be doing a nested-loop join as one would expect. In fact, the 8.5 plan looks a bit better on the surface, for example it avoids sorting the argument of the max() function into document order. The Saxon-SA8.5 plan uses a hash join, again as one would expect: it will be interesting (at least for me) to see what improvement this achieves. Clearly there was no intention that in optimizing joins for Saxon-SA, there should be any performance regression in Saxon-B, and the join benchmarks that I ran didn't show any. Michael Kay

RE: Query significantly slower in Saxon 8.5 - Added by Anonymous over 19 years ago

Legacy ID: #3280657 Legacy Poster: marcvc (marcvc)

Sure, I'll provide you those xml documents. I'm going to email them to you as I'm not sure how to attach files to these sourceforge messages. Regards, Marc

RE: Query significantly slower in Saxon 8.5 - Added by Anonymous over 19 years ago

Legacy ID: #3282750 Legacy Poster: Michael Kay (mhkay)

Turns out to be a rare performance bug that was present in Saxon 8.4, but wasn't activated by this query (or any others that I've come across!) because the optimizer produced a slightly different execution plan. I've logged the bug and provided a replacement for the MemoClosure module at https://sourceforge.net/tracker/index.php?func=detail&amp;aid=1252878&amp;group_id=29872&amp;atid=397617

    (1-3/3)

    Please register to reply