| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel query execution |
| Date: | 2013-01-17 03:32:28 |
| Message-ID: | CAMkU=1zU9myesU-z-F+a1MZC22USAirK=gyJuFJ3_HDN+h9BhQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wednesday, January 16, 2013, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us <javascript:;>) wrote:
> > I am not sure how a COPY could be easily parallelized, but I supposed it
> > could be done as part of the 1GB segment feature. People have
> > complained that COPY is CPU-bound, so it might be very interesting to
> > see if we could offload some of that parsing overhead to a child.
>
> COPY can certainly be CPU bound but before we can parallelize that
> usefully we need to solve the problem around extent locking when trying
> to do multiple COPY's to the same table.
>
I think that is rather over-stating it. Even with unindexed untriggered
tables, I can get some benefit from doing hand-rolled parallel COPY before
the extension lock becomes an issue, at least on some machines. And with
triggered or indexed tables, all the more so.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-01-17 03:40:07 | Re: CF3+4 |
| Previous Message | Bruce Momjian | 2013-01-17 03:29:24 | Re: Parallel query execution |