| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| 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 22:38:04 |
| Message-ID: | 4002.1534199884@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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?
No. At least, Materialize as it stands doesn't help. There's no
provision for pushing rowsets to parallel workers, only pulling
from them, and it would be an extremely nontrivial thing to add
AFAICS (for one thing, it'd make the leader process even more of
a bottleneck than it is already).
Maybe you could do something with dumping a rowset into a tuplestore
and forcing that out to temp files on-disk before starting any of
the parallel workers, then letting them read it in from the temp
files. But that still looks like a lot of new work and completely
not fit for back-patching, even if we had it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2018-08-14 04:10:38 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
| Previous Message | David G. Johnston | 2018-08-13 20:25:09 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |