From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
Subject: | Re: Declarative partitioning - another take |
Date: | 2017-04-26 02:43:50 |
Message-ID: | a7fc9a40-e742-2619-38dd-7c7ba156e6a1@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thanks for testing.
On 2017/04/25 19:03, Rajkumar Raghuwanshi wrote:
> Thanks for looking into it. I have applied fixes and checked for triggers.
> I could see difference in behaviour of statement triggers for INSERT and
> UPDATE, for insert only root partition triggers are getting fired but for
> update root as well as child partition table triggers both getting fired.
> is this expected??
Yes, because I didn't implement anything for the insert case yet. I posed
a question whether to fire partitions' per-statement triggers when
inserting data through the root table.
Robert replied [1] that it would be desirable to not fire partitions'
per-statement triggers if the root table is mentioned in the query; only
fire their per-row triggers if any. It already works that way for
inserts, and applying only 0001 will get you the same for update/delete.
Patch 0002 is to enable firing partition's per-statement triggers even if
the root table is mentioned in the query, but it implemented the same only
for the update/delete cases. If we decide that that's the right thing to
do, then I will implement the same behavior for the insert case too.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-04-26 03:35:04 | Re: some review comments on logical rep code |
Previous Message | Amit Langote | 2017-04-26 02:34:41 | Re: Declarative partitioning - another take |