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

From Robert Haas
Subject Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
Date
Msg-id CA+TgmoZ=6-CmSW0BkAMx_4w7wy66OS+4-LTgtn18cnLB0D4nsw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] COPY (query) TO ... doesn't allow parallelism  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, May 31, 2017 at 7:19 PM, Andres Freund <andres@anarazel.de> wrote:
> To me that appears to be an oversight rather than intentional.  A
> somewhat annoying one at that, because it's not uncommong to use COPY to
> execute reports to a CSV file and such.
>
> Robert, am I missing a complication?

No, I think that would work.

> 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?  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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

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