Re: An idea for parallelizing COPY within one backend

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: An idea for parallelizing COPY within one backend
Дата
Msg-id 47C593D0.6080600@dunslane.net
обсуждение исходный текст
Ответ на Re: An idea for parallelizing COPY within one backend  ("Florian G. Pflug" <fgp@phlo.org>)
Ответы Re: An idea for parallelizing COPY within one backend  (Brian Hurt <bhurt@janestcapital.com>)
Re: An idea for parallelizing COPY within one backend  ("Florian G. Pflug" <fgp@phlo.org>)
Список pgsql-hackers

Florian G. Pflug wrote:
>
>> Would it be possible to determine when the copy is starting that this 
>> case holds, and not use the parallel parsing idea in those cases?
>
> In theory, yes. In pratice, I don't want to be the one who has to 
> answer to an angry user who just suffered a major drop in COPY 
> performance after adding an ENUM column to his table.
>
>

I am yet to be convinced that this is even theoretically a good path to 
follow. Any sufficiently large table could probably be partitioned and 
then we could use the parallelism that is being discussed for pg_restore 
without any modification to the backend at all. Similar tricks could be 
played by an external bulk loader for third party data sources.

cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend
Следующее
От: Brian Hurt
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend