Re: Killing off removed rels properly
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-02-20T16:53:43Z
Lists: pgsql-hackers
Hmm, there's something else going on here. After getting rid of the
assertion failure, I see that the plan looks like
# explain MERGE INTO tt USING st ON tt.tid = st.sid WHEN NOT MATCHED THEN INSERT
VALUES (st.sid);
QUERY PLAN
-------------------------------------------------------------
Merge on tt (cost=0.00..35.50 rows=0 width=0)
-> Seq Scan on st (cost=0.00..35.50 rows=2550 width=10)
(2 rows)
which is fairly nonsensical and doesn't match v15's plan:
Merge on tt (cost=0.15..544.88 rows=0 width=0)
Merge on ttp tt_1
-> Nested Loop Left Join (cost=0.15..544.88 rows=32512 width=14)
-> Seq Scan on st (cost=0.00..35.50 rows=2550 width=4)
-> Index Scan using ttp_pkey on ttp tt_1 (cost=0.15..0.19 rows=1 widt
h=14)
Index Cond: (tid = st.sid)
It looks like we're somehow triggering the elide-a-left-join code
when we shouldn't? That explains why the target table's RelOptInfo
has gone missing and broken make_modifytable's expectations.
That code is still unnecessarily fragile so I intend to rearrange it,
but there's more to do here.
regards, tom lane
Commits
-
Prevent join removal from removing the query's result relation.
- f6db76c55509 16.0 landed
- e6d8639cf25c 15.3 landed
-
Remove gratuitous assumptions about what make_modifytable can see.
- c6c3b3bc3de1 16.0 landed
-
When removing a relation from the query, drop its RelOptInfo.
- e9a20e451f3a 16.0 landed
-
Allow left join removals and unique joins on partitioned tables
- 3c569049b7b5 16.0 cited