Re: pgsql: Allow UPDATE to move rows between partitions.

On Tue, Jan 23, 2018 at 9:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jan 23, 2018 at 8:44 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Sat, Jan 20, 2018 at 2:03 AM, Robert Haas <rhaas(at)postgresql(dot)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.
>

I think the problem is not only for triggers behavior but also for the
pending patch which takes care of concurrent updates/deletes. I think
in case of logical replication we won't be able to detect that the row
has been moved to another partition by the logical worker as part of
replaying the actions done on master. See my response to Amul's patch
[1].

[1] - https://www.postgresql.org/message-id/CAA4eK1LHVnNWYF53F1gUGx6CTxuvznozvU-Lr-dfE%3DQeu1gEcg%40mail.gmail.com

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com