Re: Considering additional sort specialisation functions for PG16
| От | John Naylor |
|---|---|
| Тема | Re: Considering additional sort specialisation functions for PG16 |
| Дата | |
| Msg-id | CAFBsxsGO7zBvnWStCTrDz0p6MeuRwpxC+udha-0fX-JmAJpqog@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Considering additional sort specialisation functions for PG16 (Pavel Borisov <pashkin.elfe@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Jan 26, 2023 at 6:14 PM Pavel Borisov <pashkin.elfe@gmail.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
> 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
> 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
В списке pgsql-hackers по дате отправления: