Re: Update of partition key on foreign server - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Update of partition key on foreign server
Date
Msg-id CAPmGK17BRA_MC9xqX27+q3j0b=x2R7BwYzqG0=X8L=d7daNFEg@mail.gmail.com
Whole thread Raw
In response to Re: Update of partition key on foreign server  (Ilya Gladyshev <i.gladyshev@postgrespro.ru>)
List pgsql-hackers
On Thu, Aug 26, 2021 at 11:10 PM Ilya Gladyshev
<i.gladyshev@postgrespro.ru> wrote:
> I have developed a simple patch to fix this, while I’m not fully satisfied with it, it gets the job done.

Thanks for working on this!

> In message [1] there’s also mentioned possibility of existence of triggers on the foreign server, and transforming
theupdate to delete+insert will cause these triggers to be omitted. 

Yeah, I still think so.

> While it is true, I feel like partition pruning already has a similar effect, as it allows to skip scanning foreign
partitions.

I don’t fully understand this part.  Could you elaborate a bit more on it?

> The only way to both fix the update and have the triggers work, that I came up with, is to use parent partitioned
tableas a target for the foreign update (FDW request would then be "UPDATE public.players …"), while this is possible,
itrequires the foreign server to have the same partitioned table, which seems quite restrictive to me. 

Yeah, that would be too restrictive.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)
Next
From: Fujii Masao
Date:
Subject: Re: Support reset of Shared objects statistics in "pg_stat_reset" function