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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query