Re: Instability of partition_prune regression test results

On Fri, Sep 27, 2019 at 7:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Every so often the partition_prune test falls over, for example
> here, here, and here:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2019-08-15%2021%3A45%3A00
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2019-08-21%2022%3A19%3A23
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2019-09-11%2018%3A46%3A47
>
> The reason for the failures is quite apparent: we sometimes don't
> get as many workers as we hoped for. The test script is not quite
> 100% naive about that, but it's only designed to filter out the
> "loops" counts of parallel scan nodes. As these examples show,
> that's utterly inadequate. The "Workers Launched" field is variable
> too, obviously, and so are the rows and loops counts for every plan
> node up to the Gather.
>
> I experimented with adjusting explain_parallel_append() to filter
> more fields, but soon realized that we'd have to filter out basically
> everything that makes it useful to run EXPLAIN ANALYZE at all.
>
> Therefore, I think it's time to give up this testing methodology
> as a bad idea, and fall back to the time-honored way of running a
> plain EXPLAIN and then the actual query, as per the attached patch.

Isn't the point of using ANALYZE here to show that the exec-param
based run-time pruning is working (those "never executed" strings)?

> BTW, another aspect of this test script that could stand to be
> nuked from orbit is this method for getting a custom plan:
>
> -- Execute query 5 times to allow choose_custom_plan
> -- to start considering a generic plan.
> execute ab_q4 (1, 8);
> execute ab_q4 (1, 8);
> execute ab_q4 (1, 8);
> execute ab_q4 (1, 8);
> execute ab_q4 (1, 8);
>
> We should drop that in favor of plan_cache_mode = force_custom_plan,
> IMO.

+1

Thanks,
Amit