Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Nov 24, 2023 at 8:44 AM Matthias van de Meent
> <boekewurm+postgres@gmail.com> wrote:
>> Yes, the part where btree opclasses determine a type's ordering is
>> clear. But what I'm looking for is "how do I, as an index AM
>> implementation, get the signal that I need to return column-ordered
>> data?" If that signal is "index AM marked amcanorder == index must
>> return ordered data", then that's suboptimal for the index AM writer,
>> but understandable. If amcanorder does not imply always ordered
>> retrieval, then I'd like to know how it is signaled to the AM. But as
>> of yet I've not found a clear and conclusive answer either way.
> I suppose that amcanorder=true cannot mean that, since we have the
> SAOP path key thing (at least for now).
As things stand, amcanorder definitely means that the index always
returns ordered data, since the planner will unconditionally apply
pathkeys to the indexscan Paths generated for it (see plancat.c's
get_relation_info which sets up info->sortopfamily, and
build_index_pathkeys which uses that). We could reconsider that
definition if there were a reason to, but so far it hasn't seemed
interesting. The hack in 807a40c5 is a hack, without a doubt, but
that doesn't necessarily mean we should spend time on generalizing it,
and even less that we should have done so in 2012. Maybe by now there
are non-core index AMs that have cases where it's worth being pickier.
We'd have to invent some API that allows the index AM to have a say in
what pathkeys get applied.
regards, tom lane
