On Tue, Jan 23, 2018 at 8:44 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Sat, Jan 20, 2018 at 2:03 AM, Robert Haas <rhaas@postgresql.org> wrote:
>> Allow UPDATE to move rows between partitions.
>
> + If an <command>UPDATE</command> on a partitioned table causes a row to move
> + to another partition, it will be performed as a <command>DELETE</command>
> + from the original partition followed by an <command>INSERT</command> into
> + the new partition. In this case, all row-level <literal>BEFORE</literal>
> + <command>UPDATE</command> triggers and all row-level
> + <literal>BEFORE</literal> <command>DELETE</command> triggers are fired on
> + the original partition.
>
> Do we need to maintain triggers related behavior for logical
> replication? In logical replication, we use ExecSimpleRelationDelete
> to perform Delete operation which is not aware of this special
> behavior (execute before update trigger for this case).
Hmm. I don't think there's any way for the logical decoding
infrastructure to identify this case at present. I suppose if we want
that behavior, we'd need to modify the WAL format, and the changes
might not be too straightforward because the after-image of the tuple
wouldn't be available in the DELETE record. I think the only reason
we fire the UPDATE triggers is because we can't decide until after
they've finished executing that we really want to DELETE and INSERT
instead; by the time we are replicating the changes, we know what the
final shape of the operation ended up being, so it's not clear to me
that firing UPDATE triggers at that point would be useful. I fear
that trying to change this is going to cost performance (and developer
time) for no real benefit, so my gut feeling is to leave it alone.
However, what do other people think?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
