From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Instability in partition_prune test? |
Date: | 2018-04-13 14:25:45 |
Message-ID: | 20180413142545.gc4lbnvq6owijozb@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > The attached basically adds:
> > set max_parallel_workers = 0;
>
> It seems quite silly to be asking for a parallel plan and then insisting
> it not run in parallel.
The idea is to use the parallel append code, but run it in the leader.
Now that you mention it, this probably decreases coverage for the
choose_next_subplan_for_worker function.
> Maybe the right solution is to strip out the loop_count from what's
> printed. We've already done that sort of thing in at least one other
> test, using some plpgsql code to "sed" the EXPLAIN output.
Ah, explain_parallel_sort_stats() ... maybe that's an idea, yeah.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-04-13 14:50:44 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Tom Lane | 2018-04-13 14:05:00 | Re: Instability in partition_prune test? |