From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: separate serial_schedule useful? |
Date: | 2017-10-09 10:42:19 |
Message-ID: | CAFjFpRcbE+SAcZDXw4xVWuh0u=7Ui0mdPOeOW+d1YXo0gT1wpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 7, 2017 at 10:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
Sorry, my bad. I wasn't aware of this rule. I should have looked at
the beginning of the file for any rules.
>>> There's no reason why pg_regress couldn't have a
>>> --bail-if-group-size-exceeds=N argument, or why we couldn't have a
>>> separate Perl script to validate the schedule file as part of the
>>> build process.
>
>> I'd go for the former approach; seems like less new code and fewer cycles
>> used to enforce the rule.
>
> Concretely, how about the attached? (Obviously we'd have to fix
> parallel_schedule before committing this.)
>
Thanks, this will help. May be we should set default to 20 instead of unlimited.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-10-09 10:47:52 | Re: PoC: full merge join on comparison clause |
Previous Message | Ashutosh Bapat | 2017-10-09 10:35:31 | Re: Proposal: Local indexes for partitioned table |