Re: Considering additional sort specialisation functions for PG16

I wrote:
> Have two memtuple arrays, one for first sortkey null and one for first
sortkey non-null:

Hacking on this has gotten only as far as the "compiles but segfaults"
stage, but I wanted to note an idea that occurred to me:

Internal qsort doesn't need the srctape member, and removing both that and
isnull1 would allow 16-byte "init-tuples" for qsort, which would save a bit
of work_mem space, binary space for qsort specializations, and work done
during swaps.

During heap sort, we already copy one entry into a stack variable to keep
from clobbering it, so it's not a big step to read a member from the init
array and form a regular sorttuple from it.

--
John Naylor
EDB: http://www.enterprisedb.com