|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Subject:||Re: ON COMMIT actions and inheritance|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote:
> Agree with keeping it simple. Maybe, we could (should?) document that the
> only ON COMMIT action that works when specified with partitioned parent
> table is DROP (other actions are essentially ignored)?
I have been thinking about this one, and here are some ideas:
- for ON COMMIT DROP:
When used on a partitioned table or a table with inheritance children,
this drops the depending partitions and children.
- for ON DELETE ROWS:
When used on a partitioned table, this is not cascaded to its
> Seems fine to me.
Thanks for looking at the patch.
> + /*
> + * Truncate relations before dropping so as all dependencies between
> so as -> so that
> + * relations are removed after they are worked on. This is a waste as it
> + * could be possible that a relation truncated needs also to be removed
> + * per dependency games but this makes the whole logic more robust and
> + * there is no need to re-check that a relation exists afterwards.
> + */
> "afterwords" seems redundant, but may I suggest rewriting the 2nd sentence as:
> Doing it like this might be a waste as it's possible that a relation being
> truncated will be dropped anyway due to it's parent being dropped, but
> this makes the code more robust because of not having to re-check that the
> relation exists.
Your comment sounds better, so added.
|Next Message||Imai, Yoshikazu||2018-11-07 01:00:17||RE: speeding up planning with partitions|
|Previous Message||Kyotaro HORIGUCHI||2018-11-07 00:31:36||Re: shared-memory based stats collector|