Re: Choosing parallel_degree

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, James Sewell <james(dot)sewell(at)lisasoft(dot)com>
Subject: Re: Choosing parallel_degree
Date: 2016-03-16 16:16:30
Message-ID: CA+TgmoZiYuYzx95D=e2MDDRH5WvMTpqoQccJivu06x=9A6KvPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
wrote:

> On 15/03/2016 21:12, Robert Haas wrote:
> > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley
> > <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> >> Over in [1] James mentioned about wanting more to be able to have more
> >> influence over the partial path's parallel_degree decision. At risk
> >> of a discussion on that hijacking the parallel aggregate thread, I
> >> thought I'd start this for anyone who would want to discuss making
> >> changes to that.
> >>
> >> I've attached a simple C program which shows the parallel_degree which
> >> will be chosen at the moment. For now it's based on the size of the
> >> base relation. Perhaps that will need to be rethought later, perhaps
> >> based on costs. But I just don't think it's something for 9.6.
> >
> > I thought about this a bit more. There are a couple of easy things we
> > could do here.
> >
> > The 1000-page threshold could be made into a GUC.
> >
> > We could add a per-table reloption for parallel-degree that would
> > override the calculation.
> >
> > Neither of those things is very smart, but they'd probably both help
> > some people. If someone is able to produce a patch for either or both
> > of these things *quickly*, we could possibly try to squeeze it into
> > 9.6 as a cleanup of work already done.
> >
>
> I'm not too familiar with parallel planning, but I tried to implement
> both in attached patch. I didn't put much effort into the
> parallel_threshold GUC documentation, because I didn't really see a good
> way to explain it. I'd e happy to improve it if needed. Also, to make
> this parameter easier to tune for users, perhaps we could divide the
> default value by 3 and use it as is in the first iteration in
> create_parallel_path()
>

Hmm. I'm not sure I like the parallel_threshold GUC after all. That's a
little strange. But maybe.

For the reloption, I was thinking it would be parallel_degree, not
max_parallel_degree. max_parallel_degree would still control, so if the
parallel_degree for a given table was greater than max_parallel_degree,
you'd get max_parallel_degree instead. But you could crank up the
parallel_degree for a small table to force more parallelism when querying
it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-03-16 16:19:17 Re: pg_ctl promote wait
Previous Message David Steele 2016-03-16 16:13:07 Re: PATCH: index-only scans with partial indexes