Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

Hi, Peter!

On 20.01.2024 01:41, Peter Geoghegan wrote:
> It is quite likely that there are exactly zero affected out-of-core
> index AMs. I don't count pgroonga as a counterexample (I don't think
> that it actually fullfills the definition of a ). Basically,
> "amcanorder" index AMs more or less promise to be compatible with
> nbtree, down to having the same strategy numbers. So the idea that I'm
> going to upset amsearcharray+amcanorder index AM authors is a
> completely theoretical problem. The planner code evolved with nbtree,
> hand-in-glove.

From the 5bf748b86bc commit message:

> There is a theoretical risk that removing restrictions on SAOP index
> paths from the planner will break compatibility with amcanorder-based
> index AMs maintained as extensions. Such an index AM could have the
> same limitations around ordered SAOP scans as nbtree had up until now.
> Adding a pro forma incompatibility item about the issue to the Postgres
> 17 release notes seems like a good idea.

Seems, this commit broke our posted knn_btree patch. [1]
If the point from which ORDER BY goes by distance is greater than the elements of ScalarArrayOp,
then knn_btree algorithm will give only the first tuple. It sorts the elements of ScalarArrayOp
in descending order and starts searching from smaller to larger
and always expects that for each element of ScalarArrayOp there will be a separate scan.
And now it does not work. Reproduction is described in [2].

Seems it is impossible to solve this problem only from the knn-btree patch side.
Could you advise any ways how to deal with this. Would be very grateful.

With the best wishes,

--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

[1]
https://commitfest.postgresql.org/48/4871/
[2]
https://www.postgresql.org/message-id/47adb0b0-6e65-4b40-8d93-20dcecc21395%40postgrespro.ru