I wrote:
> But while I'm looking at this, 3c569049b seems kind of broken on
> its own terms. Why is it populating so little of the IndexOptInfo
> for a partitioned index? I realize that we're not going to directly
> plan anything using such an index, but not populating fields like
> sortopfamily
I wrote:
>> It looks like we're somehow triggering the elide-a-left-join code
>> when we shouldn't?
So the reason why we see this with a partitioned target table and not
with a regular target table reduces to this bit in preprocess_targetlist:
/*
* For non-inherited UPDATE/DELETE/MERGE,
I wrote:
> 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
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
Alexander Lakhin writes:
> After this change the following query triggers an assert:
> CREATE TABLE tt (tid integer PRIMARY KEY) PARTITION BY LIST (tid);
> CREATE TABLE ttp PARTITION OF tt DEFAULT;
> CREATE TABLE st (sid integer);
> MERGE INTO tt USING st ON tt.tid = st.sid WHEN NOT MATCHED
Hello Tom,
13.02.2023 21:39, Tom Lane wrote:
Richard Guo writes:
On Sat, Feb 11, 2023 at 4:50 AM Tom Lane wrote:
I think it's time to clean this up by removing the rel from the
planner data structures altogether. The attached passes check-world,
and if it does trigger any problems I would
Richard Guo writes:
> On Sat, Feb 11, 2023 at 4:50 AM Tom Lane wrote:
>> I think it's time to clean this up by removing the rel from the
>> planner data structures altogether. The attached passes check-world,
>> and if it does trigger any problems I would say that's a clear
>> sign of bugs
On Sat, Feb 11, 2023 at 4:50 AM Tom Lane wrote:
> I think it's time to clean this up by removing the rel from the
> planner data structures altogether. The attached passes check-world,
> and if it does trigger any problems I would say that's a clear
> sign of bugs elsewhere.
+1. The patch
Outer-join removal does this:
/*
* Mark the rel as "dead" to show it is no longer part of the join tree.
* (Removing it from the baserel array altogether seems too risky.)
*/
rel->reloptkind = RELOPT_DEADREL;
which apparently I thought was a good idea in 2010 (cf
