We do what you describe for the collection and child path step. I will look at defining the some-clause in a way that can avoid the subplan for VXQuery. The subplans have been known to be bad for performance.
On Mon, Feb 10, 2014 at 9:27 AM, Till Westmann <[email protected]> wrote: > It's interesting to see, that saxon seems to do sorting and duplicate > elimination on a single child path step on top of the collection function. > I think that that should no be necessary, if > a) the result of the collection function is in document order and > b) the child path maintains the input order. > Is that right? I would assume that we don't have a duplicate elimination > step there. > > Wrt. the optimization of the some-clause, I'm pretty sure that we could > implement it, but the question is if/when we should do that. > If you can succinctly describe the optimization, could you file an issue > for this? > > Cheers, > Till > > > > On Thu, Feb 6, 2014 at 9:47 PM, Eldon Carman <[email protected]> wrote: > > > As we compare our times with saxon, attached are saxon's query execution > > plans for our benchmark queries. The plans look very similar to the query > > in structure. In our plans we have a rule that inlines assignments and > thus > > duplicates some let clauses when they are used multiple places. Saxon is > > not doing that restructuring. > > > > Just like our plans they have the initial paths steps close together. The > > plans also have similar depth related to the number of expression in the > > query. Saxon does have a optimization for the "some" clause which is not > in > > VXQuery. Not sure if that is something we can implement. > > >
