| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
| Cc: | Keith Fiske <keith(at)omniti(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Adding support for Default partition in partitioning |
| Date: | 2017-04-05 07:52:30 |
| Message-ID: | 339239fb-f7c8-9cce-8ac9-4fc68b5c9219@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017/04/05 14:41, Rushabh Lathia wrote:
> I agree about the future plan about the row movement, how that is I am
> not quite sure at this stage.
>
> I was thinking that CREATE new partition is the DDL command, so even
> if row-movement works with holding the lock on the new partition table,
> that should be fine. I am not quire sure, why row movement should be
> happen in the back-ground process.
I think to improve the availability of access to the partitioned table.
Consider that the default partition may have gotten pretty large.
Scanning it and moving rows to the newly added partition while holding an
AccessExclusiveLock on the parent will block any and all of the concurrent
activity on it until the row-movement is finished. One may be prepared to
pay this cost, for which there should definitely be an option to perform
the row-movement in the same transaction (also possibly the default behavior).
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2017-04-05 07:58:55 | Re: Outdated comments around HandleFunctionRequest |
| Previous Message | Kuntal Ghosh | 2017-04-05 07:34:16 | Re: strange parallel query behavior after OOM crashes |