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.
This commit is contained in:
David Rowley 2021-04-02 15:25:38 +13:00
parent 2bda93f813
commit a4fac4ffe8
2 changed files with 31 additions and 21 deletions

View File

@ -23,6 +23,7 @@ begin
ln := regexp_replace(ln, 'Evictions: \d+', 'Evictions: N');
ln := regexp_replace(ln, 'Memory Usage: \d+', 'Memory Usage: N');
ln := regexp_replace(ln, 'Heap Fetches: \d+', 'Heap Fetches: N');
ln := regexp_replace(ln, 'loops=\d+', 'loops=N');
return next ln;
end loop;
end;
@ -30,21 +31,24 @@ $$;
-- Ensure we get a result cache on the inner side of the nested loop
SET enable_hashjoin TO off;
SET enable_bitmapscan TO off;
-- force_parallel_mode = regress can cause some instability in EXPLAIN ANALYZE
-- output, so let's ensure that we turn it off.
SET force_parallel_mode TO off;
SELECT explain_resultcache('
SELECT COUNT(*),AVG(t1.unique1) FROM tenk1 t1
INNER JOIN tenk1 t2 ON t1.unique1 = t2.twenty
WHERE t2.unique1 < 1000;', false);
explain_resultcache
--------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=1)
-> Nested Loop (actual rows=1000 loops=1)
-> Seq Scan on tenk1 t2 (actual rows=1000 loops=1)
explain_resultcache
-------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=N)
-> Nested Loop (actual rows=1000 loops=N)
-> Seq Scan on tenk1 t2 (actual rows=1000 loops=N)
Filter: (unique1 < 1000)
Rows Removed by Filter: 9000
-> Result Cache (actual rows=1 loops=1000)
-> Result Cache (actual rows=1 loops=N)
Cache Key: t2.twenty
Hits: 980 Misses: 20 Evictions: Zero Overflows: 0 Memory Usage: NkB
-> Index Only Scan using tenk1_unique1 on tenk1 t1 (actual rows=1 loops=20)
-> Index Only Scan using tenk1_unique1 on tenk1 t1 (actual rows=1 loops=N)
Index Cond: (unique1 = t2.twenty)
Heap Fetches: N
(11 rows)
@ -63,17 +67,17 @@ SELECT explain_resultcache('
SELECT COUNT(*),AVG(t2.unique1) FROM tenk1 t1,
LATERAL (SELECT t2.unique1 FROM tenk1 t2 WHERE t1.twenty = t2.unique1) t2
WHERE t1.unique1 < 1000;', false);
explain_resultcache
--------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=1)
-> Nested Loop (actual rows=1000 loops=1)
-> Seq Scan on tenk1 t1 (actual rows=1000 loops=1)
explain_resultcache
-------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=N)
-> Nested Loop (actual rows=1000 loops=N)
-> Seq Scan on tenk1 t1 (actual rows=1000 loops=N)
Filter: (unique1 < 1000)
Rows Removed by Filter: 9000
-> Result Cache (actual rows=1 loops=1000)
-> Result Cache (actual rows=1 loops=N)
Cache Key: t1.twenty
Hits: 980 Misses: 20 Evictions: Zero Overflows: 0 Memory Usage: NkB
-> Index Only Scan using tenk1_unique1 on tenk1 t2 (actual rows=1 loops=20)
-> Index Only Scan using tenk1_unique1 on tenk1 t2 (actual rows=1 loops=N)
Index Cond: (unique1 = t1.twenty)
Heap Fetches: N
(11 rows)
@ -97,23 +101,24 @@ SELECT explain_resultcache('
SELECT COUNT(*),AVG(t1.unique1) FROM tenk1 t1
INNER JOIN tenk1 t2 ON t1.unique1 = t2.thousand
WHERE t2.unique1 < 1200;', true);
explain_resultcache
----------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=1)
-> Nested Loop (actual rows=1200 loops=1)
-> Seq Scan on tenk1 t2 (actual rows=1200 loops=1)
explain_resultcache
-------------------------------------------------------------------------------------------
Aggregate (actual rows=1 loops=N)
-> Nested Loop (actual rows=1200 loops=N)
-> Seq Scan on tenk1 t2 (actual rows=1200 loops=N)
Filter: (unique1 < 1200)
Rows Removed by Filter: 8800
-> Result Cache (actual rows=1 loops=1200)
-> Result Cache (actual rows=1 loops=N)
Cache Key: t2.thousand
Hits: N Misses: N Evictions: N Overflows: 0 Memory Usage: NkB
-> Index Only Scan using tenk1_unique1 on tenk1 t1 (actual rows=1 loops=1028)
-> Index Only Scan using tenk1_unique1 on tenk1 t1 (actual rows=1 loops=N)
Index Cond: (unique1 = t2.thousand)
Heap Fetches: N
(11 rows)
RESET enable_mergejoin;
RESET work_mem;
RESET force_parallel_mode;
RESET enable_bitmapscan;
RESET enable_hashjoin;
-- Test parallel plans with Result Cache.

View File

@ -24,6 +24,7 @@ begin
ln := regexp_replace(ln, 'Evictions: \d+', 'Evictions: N');
ln := regexp_replace(ln, 'Memory Usage: \d+', 'Memory Usage: N');
ln := regexp_replace(ln, 'Heap Fetches: \d+', 'Heap Fetches: N');
ln := regexp_replace(ln, 'loops=\d+', 'loops=N');
return next ln;
end loop;
end;
@ -32,6 +33,9 @@ $$;
-- Ensure we get a result cache on the inner side of the nested loop
SET enable_hashjoin TO off;
SET enable_bitmapscan TO off;
-- force_parallel_mode = regress can cause some instability in EXPLAIN ANALYZE
-- output, so let's ensure that we turn it off.
SET force_parallel_mode TO off;
SELECT explain_resultcache('
SELECT COUNT(*),AVG(t1.unique1) FROM tenk1 t1
INNER JOIN tenk1 t2 ON t1.unique1 = t2.twenty
@ -65,6 +69,7 @@ INNER JOIN tenk1 t2 ON t1.unique1 = t2.thousand
WHERE t2.unique1 < 1200;', true);
RESET enable_mergejoin;
RESET work_mem;
RESET force_parallel_mode;
RESET enable_bitmapscan;
RESET enable_hashjoin;