Re: Clarify the ordering guarantees in combining queries (or lack thereof)

Поиск
Список
Период
Сортировка
От Erwin Brandstetter
Тема Re: Clarify the ordering guarantees in combining queries (or lack thereof)
Дата
Msg-id CAGHENJ4yw-BcUDb2RBHQ5=Suwwg6+iwru5QBobms94_WPrff1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Clarify the ordering guarantees in combining queries (or lack thereof)  (Shay Rojansky <roji@roji.org>)
Список pgsql-docs
The manual still seems to offer just such a guarantee here:

> Multiple UNION operators in the same SELECT statement are evaluated left to right, unless otherwise indicated by parentheses.

In the case of UNION ALL, is this supposed to mean ...

a.) Individual legs are evaluated left to right, but sets returned from each are not guaranteed to be appended in the same order, nor is the order within each set guaranteed to be preserved.

b.) Individual legs are evaluated left to right, sets returned from each are appended in order, but the order within each set is not guaranteed to be preserved.

c.) Individual legs are evaluated left to right, sets returned from each are appended in order, and the order within each set is guaranteed to be preserved.

d.) The manual is outdated. Since the advent of  "Parallel Append" in Postgres 11,  left to right evaluation is not guaranteed in all cases.

Obviously, the order *within* each leg is not guaranteed without ORDER BY attached to it, enclosed in parentheses. But that's an orthogonal issue. The question is, what of the returned order is preserved after UNION ALL? And what is *guaranteed*?

I guess the term "evaluated" is ambiguous.

I would love the manual to be clear about this.

Related discussion here:

Regards
Erwin

On Mon, Jun 10, 2024 at 3:03 PM Shay Rojansky <roji@roji.org> wrote:
>> No, there is no guarantee. It's just that UNION ALL works this way today
>> (preserving the order of the subselects) - and I'm not even sure about
>> that, it may not preserve the order in all cases, with different indexes or
>> partitioning or a parallel plan, etc.
>
> Yeah, that.  You can get a parallelized plan today for UNION ALL:

...

Since the documentation doesn't make a guarantee there is none.

Thanks all for the confirmation.

I'd still suggest documenting the lack of guarantee; yes, mathematically it may be correct to not document lack of guarantees, but users can come with various expectations and misunderstandings (I also wasn't clear on this specifically for UNION ALL), and it's always good to say this kind of thing explicitly.

В списке pgsql-docs по дате отправления:

Предыдущее
От: "yanliang lei"
Дата:
Сообщение: Re:Re: Suggestion about tcp_keepalives_idle parameter in the document
Следующее
От: Will Mortensen
Дата:
Сообщение: Documenting more pitfalls of non-default collations?