Hi -list,
There is an issue with the new ResultCache machinery that we found in the wild, with a reproducible test case here:
CREATE TEMP TABLE fail (a INT PRIMARY KEY);
SELECT att.attname
FROM pg_index i
JOIN pg_class d ON d.oid = i.indrelid
JOIN generate_series(1, 32) col(i) ON col.i <= i.indnatts
LEFT JOIN pg_attribute att ON att.attrelid = d.oid AND att.attnum = i.indkey[col.i - 1]
WHERE d.relname = 'fail';
ERROR: cache entry already complete
Explain in question:
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------
Nested Loop Left Join (cost=8.59..55.26 rows=11 width=64)
Join Filter: (att.attnum = i.indkey[(col.i - 1)])
-> Nested Loop (cost=8.30..14.98 rows=11 width=35)
Join Filter: (col.i <= i.indnatts)
-> Hash Join (cost=8.30..14.26 rows=1 width=33)
Hash Cond: (i.indrelid = d.oid)
-> Seq Scan on pg_index i (cost=0.00..5.55 rows=155 width=33)
-> Hash (cost=8.29..8.29 rows=1 width=4)
-> Index Scan using pg_class_relname_nsp_index on pg_class d (cost=0.27..8.29 rows=1 width=4)
Index Cond: (relname = 'fail'::name)
-> Function Scan on generate_series col (cost=0.00..0.32 rows=32 width=4)
-> Result Cache (cost=0.29..20.34 rows=7 width=70)
Cache Key: d.oid
-> Index Scan using pg_attribute_relid_attnum_index on pg_attribute att (cost=0.28..20.33 rows=7 width=70)
Index Cond: (attrelid = d.oid)
(15 rows)
Git bisect identified this as 9eacee2e62d89cab7b004f97c206c4fba4f1d745 where the ResultCache machinery was introduced. I have not identified this further, but can help look into it.
Best,
David