On Feb 12, 2014, at 12:27 PM, Eldon Carman <[email protected]> wrote:
> 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. That'd be nice. Do we have to do this now? Cheers, Till > 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. >>> >>
