Hi, sorry for the absense. I've been back. Attached is the patch following the discussion below.
> >> (2014/04/10 0:08), Tom Lane wrote: > >>> TBH I think that's barely the tip of the iceberg of cases where this > >>> patch will get the wrong answer. > > > >>> Also, I don't see it doing anything to check the ordering > >>> of multiple index columns > > > >> I think that the following code in index_pathkeys_are_extensible() would > >> check the ordering: > >> + if (!pathkeys_contained_in(pathkeys, root->query_pathkeys)) > >> + return false; > > > > Hm ... if you're relying on that, then what's the point of the new loop > > at all? > > The point is that from the discussion [1], we allow the index pathkeys > to be extended to query_pathkeys if each *remaining* pathkey in > query_pathkey is a Var belonging to the indexed relation. The code is > confusing, though. Sorry, that is my faults. Hmm, I found that the iterations for the part that already checked by pathkeys_contained_in are not only needless but a bit heavy. And the loop seems a little verbose. I did for the patch, in index_pathkeys_are_extensible, - Avoiding duplicate check with pathkeys_contained_in. I put similar code to list_nth_cell since it is not exposed outside of list.c. - Add comment to clarify the purpose of the loop. - Simplify the check for the "remaining" keycolumns > Thanks, > > [1] http://www.postgresql.org/message-id/29637.1389064...@sss.pgh.pa.us > > Best regards, > Etsuro Fujita > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
