From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | SAIKIRAN AVULA <avulasaikiranreddy(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incorrect explain output for updates/delete operations with returning-list on partitioned tables |
Date: | 2024-05-06 21:18:31 |
Message-ID: | 3797212.1715030311@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
SAIKIRAN AVULA <avulasaikiranreddy(at)gmail(dot)com> writes:
> I have been working on partitioned tables recently, and I have noticed
> something that doesn't seem correct with the EXPLAIN output of an
> update/delete query with a returning list.
What do you think is not right exactly? The output has to use some
one of the correlation names for the partitioned table. I think
it generally chooses the one corresponding to the first Append arm,
but really any would be good enough for EXPLAIN's purposes.
> 1. In the 'grouping_planner()' function, while generating paths for the
> final relation (
> https://github.com/postgres/postgres/blob/master/src/backend/optimizer/plan/planner.c#L1857)
> we only take care of adjusting the append_rel_attributes in returningList
> for resultRelation. Shouldn't we do that for other relations as well in
> query?
If the only difference is which way variables get labeled in EXPLAIN,
I'd be kind of disinclined to spend extra cycles. But in any case,
I rather suspect you'll find that this actively breaks things.
Whether we change the varno on a Var isn't really optional, and there
are cross-checks in setrefs.c to make sure things match up.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-05-06 21:23:24 | Re: Weird test mixup |
Previous Message | David Rowley | 2024-05-06 21:08:57 | Re: 2024-05-09 release announcement draft |