Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
Date
Msg-id 20170601200204.6zjh7p4lzjqxp4p6@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2017-06-01 15:56:35 -0400, Robert Haas wrote:
> > I personally think we should fix this in 9.6 and 10, but I've to admit
> > I'm not entirely impartial, because Citus hit this...
> 
> I guess it's a matter of judgement whether you want to call this a bug
> or a missing feature.  I wasn't really laboring under any illusion
> that I'd found every place that could benefit from a
> CURSOR_OPT_PARALLEL_OK marking, so it may be that in the future we'll
> find more such places and, well, where do you draw the line?

I agree that there's degrees here.  The reason I think this is on the
"backpatch" side of the fence is that IME COPY (query) is one of the
most common ways start start a longrunning query, which isn't the case
for some of the other ways to trigger them.


> That having been said, I don't know of any particular reason why this
> particular change would carry much risk.  My tolerance for optional
> changes in back branches is lower than many people here, so if it were
> me, I'd probably fix it only in master.  However, I can't get too
> excited about it either way.

So far I plan to push a fix to both branches, unless some other people
raise a bit stronger objections. I've some things I want to push first
(sequence stuff), so there's definitely some more time for protest.

- Andres



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
Next
From: Jeevan Ladhe
Date:
Subject: Re: [HACKERS] BEFORE trigger can cause undetected partitionconstraint violation