I wrote: > Kyotaro HORIGUCHI wrote: > > Another is, you changed pathkeys expantion to be all-or-nothing decision. > > While this change should simplify the code slightly, it also dismisses > > the oppotunity for partially-extended pathkeys. Could you let me know > > the > reason > > why you did so.
> At first I thought the partially-extended pathkey list that is made from > query_pathkeys, as you proposed in the original versions of the patch. But > I've started to doubt whether it's worth doing that because I think the > partially-extended pathkey list is merely one example while the original > pathkey list can be partially-extended in different ways, ie, ISTM the > partially-extended pathkey list doesn't necessarily have the optimality > in anything significant. We might be able to partially-extend the original > pathkey list optimally in something significant, but that seems useless > complexity to me. So, I modified the patch to do the all-or-nothing > decision. Here I mean the optimality for use in merge joins. Thanks, 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
