| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Andres Freund <andres(at)anarazel(dot)de>, "andy(at)prestigedigital(dot)com" <andy(at)prestigedigital(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
| Date: | 2018-08-13 20:25:09 |
| Message-ID: | CAKFQuwYO_WMdSu4hPZDU-mYuFSqX2+o2ZhjgH8Csy574zU=UuA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Monday, August 13, 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2018-08-13 19:26 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-08-13 22:38:04 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
| Previous Message | Tom Lane | 2018-08-13 18:04:47 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |