Re: Parallel query execution
От | Bruce Momjian |
---|---|
Тема | Re: Parallel query execution |
Дата | |
Msg-id | 20130116171142.GA1099@momjian.us обсуждение исходный текст |
Ответ на | Re: Parallel query execution (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Parallel query execution
|
Список | pgsql-hackers |
On Wed, Jan 16, 2013 at 01:37:28PM +0900, Michael Paquier wrote: > > > On Wed, Jan 16, 2013 at 1:32 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: > > > > > > On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus <josh@agliodbs.com> wrote: > > > > Claudio, Stephen, > > > > It really seems like the areas where we could get the most "bang for > the > > buck" in parallelism would be: > > > > 1. Parallel sort > > 2. Parallel aggregation (for commutative aggregates) > > 3. Parallel nested loop join (especially for expression joins, like > GIS) > > > > parallel data load? :/ > > We have that in pg_restore, and I think we are getting parallel dump in > 9.3, right? Unfortunately, I don't see it in the last 9.3 commit-fest. > Is it still being worked on? > > Not exactly, I meant something like being able to use parallel processing when > doing INSERT or COPY directly in core. If there is a parallel processing > infrastructure, it could also be used for such write operations. I agree that > the cases mentioned by Josh are far more appealing though... 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: