Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
| От | David G. Johnston |
|---|---|
| Тема | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
| Дата | |
| Msg-id | CAKFQuwYO_WMdSu4hPZDU-mYuFSqX2+o2ZhjgH8Csy574zU=UuA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
|
| Список | pgsql-bugs |
On Monday, August 13, 2018, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2018-08-13 19:26 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> Likely, we need to treat the presence of a LIMIT/OFFSET in a sub-select
>> as making it parallel-unsafe, for exactly the reason that that makes
>> its results non-deterministic.
> Isn't it default behave of LIMIT/OFFSET without ORDER BY clause?
In principle, the planner could prove in some cases that the results
were deterministic even with LIMIT/OFFSET. BuT I doubt it's worth
the trouble. I certainly wouldn't advocate for such logic to be
part of a back-patched bug fix.
Could the planner stick a materialize node there that feeds the same set of originally selected records to any parallel executors that end up pulling from it?
David J.
В списке pgsql-bugs по дате отправления: