From: | David Rowley <drowley(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Attempt to fix unstable Result Cache regression tests |
Date: | 2021-04-02 02:26:00 |
Message-ID: | E1lS9VY-0006KF-Rw@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Attempt to fix unstable Result Cache regression tests
force_parallel_mode = regress is causing a few more problems than I
thought. It seems that both the leader and the single worker can
contribute to the execution. I had mistakenly thought that only the worker
process would do any work. Since it's not deterministic as to which
of the two processes will get a chance to work on the plan, it seems just
better to disable force_parallel_mode for these tests. At least doing
this seems better than changing to EXPLAIN only rather than EXPLAIN
ANALYZE.
Additionally, I overlooked the fact that the number of executions of the
sub-plan below a Result Cache will execute a varying number of times
depending on cache eviction. 32-bit machines will use less memory and
evict fewer tuples from the cache. That results in the subnode being
executed fewer times on 32-bit machines. Let's just blank out the number
of loops in each node.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/a4fac4ffe8f8d543a10ac7debf1157e34963ece3
Modified Files
--------------
src/test/regress/expected/resultcache.out | 47 +++++++++++++++++--------------
src/test/regress/sql/resultcache.sql | 5 ++++
2 files changed, 31 insertions(+), 21 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2021-04-02 07:27:42 | pgsql: Fix typos in comments. |
Previous Message | Bruce Momjian | 2021-04-02 01:17:41 | pgsql: doc: mention that intervening major releases can be skipped |