Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism |
Дата | |
Msg-id | 20170601200204.6zjh7p4lzjqxp4p6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: