From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: A problem in ExecModifyTable |
Date: | 2021-08-17 05:41:16 |
Message-ID: | CAApHDvoFokcvu_T2krcxH9nXHrj2SNcVaMxBS9wMix2cke1ofQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 17 Aug 2021 at 15:56, 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)com> wrote:
> According to my understanding, the parent table of a partitioned table does not store any tuples.
> Then why is "relkind = = RELKIND_PARTITIONED_TABLE" suddenly added here ?
We'll need some sort of ResultRelInfo in the case that all partitions
are pruned. Using the one for the partitioned table is convenient. I
believe that's required if there are any statement-level triggers on
the partitioned table or if there's a RETURNING clause.
> There is no comment on this point in the code.
> Can you answer my confusion? Be deeply grateful.
Yeah maybe. It's not exactly close by, but one in grouping_planner
mentions this:
/*
* We managed to exclude every child rel, so generate a
* dummy one-relation plan using info for the top target
* rel (even though that may not be a leaf target).
* Although it's clear that no data will be updated or
* deleted, we still need to have a ModifyTable node so
* that any statement triggers will be executed. (This
* could be cleaner if we fixed nodeModifyTable.c to allow
* zero target relations, but that probably wouldn't be a
* net win.)
*/
David
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2021-08-17 06:28:24 | Re: Diagnostic comment in LogicalIncreaseXminForSlot |
Previous Message | Amit Kapila | 2021-08-17 05:35:26 | Re: Skipping logical replication transactions on subscriber side |