Thank you, > > One is, you put the added code for getrelation_info() out of the block for > > the condition (info->relam == BTREE_AM_OID) (though amcanorder would be .. > By checking the following equation in build_index_paths(), the updated > version of the patch guarantees that the result of an index scan is ordered: > > index_is_ordered = (index->sortopfamily != NULL);
Oops.. I forgot about it although many times I've seen... You're right. > > > 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. ... > > 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. Ok, I'll follow your advice. I agree on the point about merit vs complexity. I'm convinced of the validity of your patch. I'm satisfied with it. Thank you. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
