On Wed, Jan 9, 2019 at 5:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (7) At this point we're resuming the tba indexscan with a different
> value for tc.id than it was started with. The results of that are
> undefined, IMO, but what's apparently happening is that it fails to
> match some rows that it otherwise would have matched. So the end
> result is some rows are missing from the output.
Oops.
> One way we could deal with this, perhaps, is to decide that NestLoopParams
> above and below a Gather can't share PARAM_EXEC slots. I'm not sure how
> we'd mechanize that, other than not allowing NestLoopParams to share
> PARAM_EXEC slots *ever*, which might not really be that much of a cost.
>
> But TBH the whole thing frightens me quite a lot as to what other
> serial-processing assumptions are getting broken by plopping Gather
> into the middle of a plan tree. I wonder whether we'd not be best
> off disallowing this sort of plan shape, and/or forbidding the leader
> from also executing the parallelized subplan.
FWIW, I would be inclined to blame this on me not really understanding
the Param machinery very well rather than any more general brand of
insanity. I wouldn't be a bit shocked if this is not the last bit
Param-related dumbness than parallel query has. I did *try* to get it
right, but I find that stuff to be pretty arcane and not entirely
well-documented.
As to disallow "this plan shape," both leader participation and the
ability to generate this kind of plan are there because they improve
performance substantially on some queries. I put a heck of a lot of
energy into being able to parallelize only part of a query, and into
allowing for leader participation, and I believe those things make a
real difference.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
