On Fri, 21 May 2021 at 10:22, David Rowley <dgrowleyml@gmail.com> wrote:
> I've just had a quick look so far. EXPLAIN VERBOSE shows that for some
> reason the join to pg_attribute.attrelid is unique.
>
> Nested Loop Left Join (cost=8.59..55.40 rows=11 width=64)
> Output: att.attname
> Inner Unique: true
>
> I'm not quite sure why it came to that conclusion, there's certainly
> no unique index on that column.
It looks like I've incorrectly assumed that if the join is unique that
we can always mark cache entries as completed after getting 1 row.
The problem is that the join condition to pg_attribute is:
att.attrelid = d.oid AND att.attnum = i.indkey[col.i - 1] but we only
parameterize the attrelid, as you can see in:
-> 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)
this means that the cache can receive multiple records, despite the
join being inner_unique == true. The additional rows are filtered out
later in the join condition. (Join Filter: (att.attnum =
i.indkey[(col.i - 1)]))
I'll need to add a check to ensure the parameters include the entire
join condition when determining if the cache can be used in
"singlerow" mode.
I've attached a very quick patch which appears to fix the problem.
I'll need to take a bit more time to check if that's a safe way to
check if the entire join clause is parameterized or not.
(It would also be nice if the remaining join condition could be moved
into the index filter condition as this would save having to cache
rows we'll never need. I'm not going to fix that here though)
David