On 9 May 2016 at 09:12, Clément Prévost <prevostclement@gmail.com> wrote:
> The entire parallel.c reported test coverage is zero:
> http://coverage.postgresql.org/src/backend/access/transam/parallel.c.gcov.html
>
> It seem that it's not covered by the original 924bcf4f commit but I don't
> know if it's on purpose. This feature being really new that would be
> understandable.
>
> If it's not, my first idea would be to fix this by adding a simple sql test
> in /src/test/regress, in the "sql" and "expected" subdirectories that
> explain (cost off) some queries.
> I'm also guessing here that we can force a query to have a parallel plan
> with some cost magic to avoid dealing with sufficiently large datasets.
I'm not entirely sure which machine generates that coverage output,
but the problem with it is that it's just one machine. We do have at
least one buildfarm member which runs with force_parallel_mode =
regress. See http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mandrill&br=HEAD
If the coverage was run from that machine then you'd see something
higher than 0% on parallel.c.
It would be nice to improve this a bit and have the planner generate a
handful of parallel plans even without force_parallel_mode = regress.
I do believe we can now do this without having to create large tables
in the regression tests if we set parallel_setup_cost to something
low, perhaps 0 and set the table's parallel_degree to something higher
than 1. The problem with that is knowing what should actually be
tested. It seems like pretty much any plan which can generate a
parallel query is a good candidate for writing a test for, which makes
the choices for which tests to write quite hard. It makes you realise
why Robert when down the force_parallel_mode = regress path instead.
-- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
