Re: Get more from indices.

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