Attempt to fix unstable Result Cache regression tests
David Rowley <drowley@postgresql.org>
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.
Files
| Path | Change | +/− |
|---|---|---|
| src/test/regress/expected/resultcache.out | modified | +26 −21 |
| src/test/regress/sql/resultcache.sql | modified | +5 −0 |