On Wed, Jun 7, 2017 at 1:59 AM, amul sul <sula...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
