Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: "David G. Johnston" <david.g.johnston@gmail.com>

Cc: Pavel Stehule <pavel.stehule@gmail.com>, Marko Tiikkaja <marko@joh.to>, Andres Freund <andres@anarazel.de>, "andy@prestigedigital.com" <andy@prestigedigital.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>

Date: 2018-08-13T22:38:04Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Don't allow LIMIT/OFFSET clause within sub-selects to be pushed to workers.
- 568b4e1fdeb3 9.6.11 landed
- 1ceb103e7d1e 10.6 landed
- 830d7565902f 11.0 landed
- 75f9c4ca5a80 12.0 landed
Back-patch "Fix parallel hash join path search."
- 271b678436ce 9.6.11 landed
Prohibit pushing subqueries containing window function calculation to
- f658235a448a 9.6.11 landed
- bf61873ae3b6 10.6 landed
- 14e9b2a752ef 12.0 landed
- 2ce253cf57b1 11.0 landed
Fix parallel hash join path search.
- 655393a022bd 10.0 cited

"David G. Johnston" <david.g.johnston@gmail.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