Re: Instability of partition_prune regression test results
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-27T15:59:03Z
Lists: pgsql-hackers
Attachments
- change-parallel-append-testing-2.patch (text/x-diff) patch
Amit Langote <amitlangote09@gmail.com> writes: > On Fri, Sep 27, 2019 at 7:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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)? Hm. Well, if you want to see those, we could do it as attached. regards, tom lane
Commits
-
Rely on plan_cache_mode to force generic plans in partition_prune test.
- d52eaa094847 13.0 landed
-
Improve stability of partition_prune regression test.
- 9de7ea6aca5a 12.0 landed
- 4ea03f3f4eba 13.0 landed
- 0baa55655e05 11.6 landed