From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: David Fetter <david@fetter.org>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Declarative partitioning
Date: Fri, 21 Aug 2015 14:47:50 +0900
Message-ID: <55D6BB86.8030105@lab.ntt.co.jp> (raw)
In-Reply-To: <20150820131902.GB8691@fetter.org>
References: <55D3093C.5010800@lab.ntt.co.jp>
<20150818134323.GC18054@fetter.org>
<55D4309F.8030601@lab.ntt.co.jp>
<20150819125239.GE11258@fetter.org>
<55D5A4C0.4040900@lab.ntt.co.jp>
<20150820131902.GB8691@fetter.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2015-08-20 PM 10:19, David Fetter wrote:
> On Thu, Aug 20, 2015 at 06:58:24PM +0900, Amit Langote wrote:
>>
>> Ah, I understand the point of parameterization (TRUST). Seems like it
>> would be good to have with appropriate documentation of the same. Perhaps,
>> it might as well a parameter to the step 1 itself.
>
> So TRUST would obviate step 2? Better still!
>
I really wish we could do this in one step, but...
As you know, primary intention behind keeping step 2 separate is to do the
heavy validation work with access exclusive lock on the other table
instead of on the master table.
Assuming we add TRUST TO step 1 (with implications clarified in docs),
when/if the user does not use TRUST, the default behavior being to perform
the validation, would it be OK as it would have to take the expensive lock
on the master table?
Motivation for keeping the step 2 (and TRUST parameter with it) is really
to avoid this last concern.
All that said, we'd still need some way to tell rows that came from a
TRUSTed table but do not really belong to the partition because we skipped
checking that at all. Obviously one can always write a query on the
partition that can find them, but some form of DDL would be what people
might expect.
>>
>> Do you mean ATTACH and DETACH, if they require access exclusive lock on
>> the parent, should not be in the first cut? Or am I misreading?
>
> Sorry I was unclear.
>
> ATTACH and DETACH should be in the first cut even if they require an
> access exclusive lock.
>
Ah, got it.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: Langote_Amit_f8@lab.ntt.co.jp, david@fetter.org
Subject: Re: Declarative partitioning
In-Reply-To: <55D6BB86.8030105@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox