| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| Cc: | Brian Hurt <bhurt(at)janestcapital(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: An idea for parallelizing COPY within one backend |
| Date: | 2008-02-27 16:46:08 |
| Message-ID: | 47C593D0.6080600@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brian Hurt | 2008-02-27 16:53:04 | Re: An idea for parallelizing COPY within one backend |
| Previous Message | Tom Lane | 2008-02-27 16:41:02 | Re: An idea for parallelizing COPY within one backend |