Re: Parallel Aggregate - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel Aggregate
Date
Msg-id CA+TgmobYivNCKGQJikr+JtFus1jWdCiLwtVpFyEr_ju4yMJ99A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Aggregate  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Parallel Aggregate
List pgsql-hackers
On Thu, Mar 10, 2016 at 6:42 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> Hmm, it appears I only looked as far as the enum declaration, which I
> expected to have something. Perhaps I'm just not used to looking up
> the manual for things relating to code.

I don't mind adding some comments there, it just didn't seem all that
important to me.  Feel free to propose something.

> The one reason that I asked about force_parallel_mode was that I
> assumed there was some buildfarm member running somewhere that
> switches this on and runs the regression tests. I figured that if it
> exists for other parallel features, then it probably should for this
> too. Can you explain why you think this should be handled differently?

Yeah, I think Noah set up such a buildfarm member, but I can't
remember the name of it off-hand.

I think running the tests with this patch and
force_parallel_mode=regress, max_parallel_degree>0 is a good idea, but
I don't expect it to turn up too much.  That configuration is mostly
designed to test whether the basic parallelism infrastructure works or
breaks things.  It's not intended to test whether your parallel query
plans are any good - you have to write your own tests for that.

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



pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: Crash with old Windows on new CPU
Next
From: Alexey Grishchenko
Date:
Subject: Endless loop calling PL/Python set returning functions