Re: Update of partition key on foreign server

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Ilya Gladyshev <i(dot)gladyshev(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Update of partition key on foreign server
Date: 2021-09-01 11:59:56
Message-ID: CAPmGK17BRA_MC9xqX27+q3j0b=x2R7BwYzqG0=X8L=d7daNFEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 26, 2021 at 11:10 PM Ilya Gladyshev
<i(dot)gladyshev(at)postgrespro(dot)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 the update 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 table as a target for the foreign update (FDW request would then be "UPDATE public.players …"), while this is possible, it requires 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-09-01 12:01:15 Re: Support reset of Shared objects statistics in "pg_stat_reset" function
Previous Message Amit Kapila 2021-09-01 11:53:13 Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)