Skip site navigation (1) Skip section navigation (2)

Re: Parallel query execution

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel query execution
Date: 2013-01-16 04:37:28
Message-ID: CAB7nPqSnwdE-FNinbpSvAz2pwtgNQ4e+9MJOJEZRQ+AtrGoTWQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jan 16, 2013 at 1:32 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)agliodbs(dot)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 thinnk 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...
-- 
Michael Paquier
http://michael.otacoo.com

In response to

Responses

pgsql-hackers by date

Next:From: Claudio FreireDate: 2013-01-16 04:47:21
Subject: Re: Parallel query execution
Previous:From: Bruce MomjianDate: 2013-01-16 04:32:54
Subject: Re: Parallel query execution

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group