Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode

On Wed, Mar 24, 2021 at 2:42 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > On 2021-Mar-23, Robert Haas wrote:
> >> Likewise, the XXX comment you added to max_parallel_hazard_walker
> >> claims that some of the code introduced there is to compensate for an
> >> unspecified bug in the rewriter.
>
> > I think the CTE bug is this one:
> > https://www.postgresql.org/message-id/flat/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g(at)mail(dot)gmail(dot)com
> > while I can't disagree with the overall conclusion that it seems safer
> > to revert parallel INSERT/SELECT given the number of alleged problems,
> > it is true that this bug exists, and has gone unfixed.
>
> Yeah, because it's not totally clear whether we want to fix it by
> disallowing the case, or by significantly changing the way the
> rewriter works. It'd be good if some of the folks on this thread
> weighed in on that choice.
>
> (Having said that, another complaint about this particular comment
> is that it doesn't mention how the planner should be changed once
> the rewriter is fixed. Is it sufficient to delete the stanza below
> the comment?
>

Yes.

> Just looking at it, I wonder whether
> max_parallel_hazard_walker is now being invoked on portions of the
> Query tree that we'd not have to traverse at all given a rewriter fix.)
>

I remember that I have debugged that part and information was
available, so decided to add a check based on that. I just went with
your analysis in the CTE bug discussion that it is not worth and OTOH
here that information was available, so I thought that it might be a
good compromise but still, I or someone else could have weighed in on
that choice.

--
With Regards,
Amit Kapila.