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
Hi,
Over in [0] and [1] there are patches that touch on the topic of
'natual ordering' index retrieval, and [2] also touches on the topic.
For those patches, I've been looking at how the planner and executor
indicate to index AMs that they expects the output to be ordered, and
how this ordering sh
