On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> As of HEAD it is possible to get through all of our regression tests
> with these settings:
> alter system set force_parallel_mode = regress;
> alter system set max_parallel_workers_per_gather = 2;
> alter system set parallel_tuple_cost = 0;
> alter system set parallel_setup_cost = 0;
> alter system set min_parallel_relation_size = 0;
> although there are quite a number of cosmetic differences in the outputs
> for the core regression tests.  (Curiously, contrib, pl, and isolation
> seem to pass without any diffs.)  In view of the number of bugs we've been
> able to identify with this setup, it would be nice to reduce the volume of
> the cosmetic differences to make it easier to review the diffs by hand.
> I'm not sure there's much that can be done about the row-ordering diffs;
> some randomness in the output order from a parallel seqscan seems
> inevitable.  But we could tamp down the EXPLAIN output differences, which
> are much harder to review anyway.
> With that thought in mind, I propose that the behavior of
> force_parallel_mode = regress is ill-designed so far as EXPLAIN is
> concerned.  What it ought to do is suppress *all* Gathers from the output,
> not just ones that were added in response to force_parallel_mode itself.

No, that doesn't sound like a very good idea.  If you do that, then
you have no hope of the differences being *zero*, because any place
that the regression tests are intended to produce a parallel plan is
going to look different.  The charter of force_parallel_mode=regress
is that any regression test that passes normally should still pass
with that setting.  This change would clearly break that.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to