-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Matrigali wrote:
> I have always thought one hole in the derby query processing strategy > is that it does not support any sort of sort/merge query node. Could > your new node be used for this? > > Does your code take advantage of the case when the rows are already > sorted? I believe the following case is very common: I was going to ask the same question, and have two additional thoughts: - - It seems that if the sort is on top of a table access then if sort avoidance doesn't happen automatically then something is wrong with Derby optimizer. At least if the query nodes are all plug and play then it seems it should come for free. I.e. the sort on top of a table access should optimize independent of what is above it in the tree. - - It also seems that intersect could use any unique index that exists on a sub-set of the intersect columns, thus some optimize step for intersect could cost various column orders, or look for unique indexes. Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBufn7Iv0S4qsbfuQRAlSfAKCDbWjOiEadHAz0whUUZ/oxvcuQ7gCfXEeu 0MAcaqRGbwomvrSS+w6bjcg= =TCTt -----END PGP SIGNATURE-----
