pgsql: Attempt to fix unstable Result Cache regression tests
От | David Rowley |
---|---|
Тема | pgsql: Attempt to fix unstable Result Cache regression tests |
Дата | |
Msg-id | E1lS9VY-0006KF-Rw@gemulon.postgresql.org обсуждение исходный текст |
Список | 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(-)
В списке pgsql-committers по дате отправления: