Re: Adding support for Default partition in partitioning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: amul sul <sulamul(at)gmail(dot)com>
Cc: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding support for Default partition in partitioning
Date: 2017-06-08 16:49:37
Message-ID: CA+Tgmob_RcqYgbrUKo1X=tD6OA1Ty+PkH-+t0yCvZXBuuvSPrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 7, 2017 at 1:59 AM, amul sul <sulamul(at)gmail(dot)com> wrote:
> But Ashutosh's suggestion make sense, we might have constraints other
> than that partitioning constraint on default partition. If those
> constraints refutes the new partition's constraints, we should skip
> the scan.

Right. If the user adds a constraint to the default partition that is
identical to the new partition constraint, that should cause the scan
to be skipped.

Ideally, we could do even better. For example, if the user is
creating a new partition FOR VALUES IN (7), and the default partition
has CHECK (key != 7), we could perhaps deduce that the combination of
the existing partition constraint (which must certainly hold) and the
additional CHECK constraint (which must also hold, at least assuming
it's not marked NOT VALID) are sufficient to prove the new check
constraint. But I'm not sure whether predicate_refuted_by() is smart
enough to figure that out. However, it should definitely be smart
enough to figure out that if somebody's added the new partitioning
constraint as a CHECK constraint on the default partition, we don't
need to scan it.

The reason somebody might want to do that, just to be clear, is that
they could do this in multiple steps: first, add the new CHECK
constraint as NOT VALID. Then VALIDATE CONSTRAINT. Then add the new
non-default partition. This would result in holding an exclusive lock
for a lesser period of time than if they did it all together as one
operation.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-06-08 16:56:10 Re: Adding support for Default partition in partitioning
Previous Message Masahiko Sawada 2017-06-08 16:31:55 Re: Long binded parameter value in the postgres log