On Fri, 24 Nov 2023, 19:58 Tom Lane, wrote:
>
> Peter Geoghegan writes:
> > On Fri, Nov 24, 2023 at 8:44 AM Matthias van de Meent
> > 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
> >> implementati
On Fri, Nov 24, 2023 at 10:58 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > 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 pl
Peter Geoghegan writes:
> On Fri, Nov 24, 2023 at 8:44 AM Matthias van de Meent
> 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
>>
On Fri, Nov 24, 2023 at 8:44 AM Matthias van de Meent
wrote:
> Also, was that a confirmation that amcanorder is a requirement for the
> AM to return data in index order (unless amrescan's orderbys is not
> null), or just a comment on the reason for the name of 'amcanorder'
> being unclear?
It was
On Thu, 23 Nov 2023 at 19:52, Peter Geoghegan wrote:
>
> On Thu, Nov 23, 2023 at 9:16 AM Matthias van de Meent
> wrote:
> > For example, btree ignores any ordering scan keys that it is given in
> > btrescan, which seems fine for btree because the ordering of a btree
> > is static (and no other or
On Thu, Nov 23, 2023 at 11:15 AM Tom Lane wrote:
> Agreed on that, but I don't have that hard a time imagining cases
> where it might be useful for btree not to guarantee ordered output.
> IIRC, it currently has to do extra pushups to ensure that behavior
> in ScalarArrayOp cases. We've not bothe
Peter Geoghegan writes:
> On Thu, Nov 23, 2023 at 9:16 AM Matthias van de Meent
> wrote:
>> Is returning index scan results in (reverse) natural order not
>> optional but required with amcanorder? If it is required, why is the
>> am indicator called 'canorder' instead of 'willorder', 'doesorder'
On Thu, Nov 23, 2023 at 9:16 AM Matthias van de Meent
wrote:
> For example, btree ignores any ordering scan keys that it is given in
> btrescan, which seems fine for btree because the ordering of a btree
> is static (and no other order than that is expected apart from it's
> reverse order), but th
