From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | 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-15 20:12:23 |
Message-ID: | CA+TgmoYSsSL7AKQstOWskdXzzNJ9ezyG7v+vPrKG3bk5YChGKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2016-03-15 20:19:09 | Re: Small patch: fix warnings during compilation on FreeBSD |
Previous Message | Stephen Frost | 2016-03-15 19:54:36 | Re: [PATCH v6] GSSAPI encryption support |