Re: Considering additional sort specialisation functions for PG16

On Thu, Jan 26, 2023 at 6:14 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
wrote:

> > - Only if there is more than one sort key, qsort the null array.
Ideally at some point we would have a method of ignoring the first sortkey
(this is an existing opportunity that applies elsewhere as well).

> Should we need to sort by the second sort key provided the first one
> in NULL by standard or by some part of the code relying on this? I

I'm not sure I quite understand the question.

If there is more than one sort key, and the specialized comparison on the
first key gives a definitive zero result, it falls back to comparing all
keys from the full tuple. (The sorttuple struct only contains the first
sortkey, which might actually be an abbreviated key.) A possible
optimization, relevant here and also elsewhere, is to compare only using
keys starting from key2. But note: if the first key is abbreviated, a zero
result is not definitive, and we must check the first key's full value from
the tuple.

> suppose NULL values in the first sort key mean attribute values are
> undefined and there is no preferred order between these tuples, even
> if their second sort keys are different.

There is in fact a preferred order between these tuples -- the second key
is the tie breaker in this case.

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