| From: | Shay Rojansky <roji(at)roji(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pantelis Theodosiou <ypercube(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
| Subject: | Re: Clarify the ordering guarantees in combining queries (or lack thereof) |
| Date: | 2022-07-14 14:43:00 |
| Message-ID: | CADT4RqCLZS+n9Ar5mdL6H9iZPia2yqGFHVihWOh3L4zSPYvCbA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
>> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-07-14 16:09:24 | Re: How to reference the type of lock in the documentation. |
| Previous Message | PG Doc comments form | 2022-07-14 12:47:18 | pg_advisory_unlock(null) |