Robert Haas <robertmhaas@gmail.com> writes:
> That doesn't seem very hard on its face. The trick is what to do with
> that information once you've got it. As far as I can tell, you need
> to drill some kind of hole that lets you pass "additional details
> about the desired sort order" to the index AM.
We clearly need to add additional information to IndexScan plan nodes
to tell the index AM which sort order is required. Up to now, an
indexscan has only had one possible resultant sort order (two if you
count backwards scan, but as I said I don't think generalizing that
particular feature is the way to approach this). I would imagine
that the best way to handle that is to add a PathKey list or something
equivalent to it, and add that to the arguments passed to ambeginscan.
The other issue is how the planner can figure out what the possible
orderings are when it's considering an index. You seem to be
contemplating adding a new index AM function that the planner would call
at the right point; but I'm not sure that that adds much of anything,
because the index AM can't have hard-wired behavior either. We really
have to have enough information in the system catalog entries about an
opclass to allow the possible orderings to be determined. Given that,
I think it makes more sense for the core planner to know what to do than
to put possibly duplicative code into multiple AMs.
I guess a third alternative would be to create per-opclass hook
functions for the planner to call, but I'm not thrilled with that
idea; it would still be largely duplicative code, and in a lot more
places. I think it would also bind our hands with respect to making
internal planner changes in future, because the data structures
representing pathkeys would be pretty well locked down by such a choice.
regards, tom lane