Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
От | Tom Lane |
---|---|
Тема | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode |
Дата | |
Msg-id | 1011362.1616533949@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
|
Список | pgsql-committers |
Alvaro Herrera <alvherre@alvh.no-ip.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@mail.gmail.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? 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.) regards, tom lane
В списке pgsql-committers по дате отправления: