Re: Quickselect instead of a heap for ORDER BY ... LIMIT N large bounded sorts

Hello,

v3 attached, rebased on master (4f89416c9db). One fix: v2 fails the
contrib/cube regression test. I only ran the core regression suite
before posting v2, sorry about that.

The cube test runs ORDER BY c~>2 LIMIT 15 once as a GiST ordered index
scan and once as a seq scan plus sort, and expects the same output. Two
rows tie on c~>2 = 270. SQL leaves their order unspecified, and the
heap happened to return them in the same order the index does.
Quickselect returns them the other way around. Same build with
debug_topn_quickselect=off passes, so it is the patch and not something
else.

0001 now adds c~>4 as a tiebreaker to that one query in the seq-scan
block, which keeps both blocks' expected output identical. The commit
message mentions the tie order change. Nothing else in the full suite
changed. The code in 0001-0003 is the same as v2.

All meson suites, with cassert and PG_TEST_EXTRA="ssl ldap kerberos
load_balance libpq_encryption wal_consistency_checking xid_wraparound
oauth" on Debian 13 (gcc 14): 414 pass, 0 fail, 20 skipped (Windows-only
or opt-in tests). CI on the fork is green as well.

best.

-greg