Re: Constraint exclusion and overlapping range checks - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Constraint exclusion and overlapping range checks
Date
Msg-id FDA1B9A1-1383-4D0F-B2DB-207DE24E06F9@gmail.com
Whole thread Raw
In response to Re: Constraint exclusion and overlapping range checks  (Steve Atkins <steve@blighty.com>)
Responses Re: Constraint exclusion and overlapping range checks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sep 7, 2013, at 6:54, Steve Atkins <steve@blighty.com> wrote:

> On Sep 6, 2013, at 9:37 PM, François Beausoleil <francois@teksol.info> wrote:
>
>> Le 2013-09-07 à 00:29, Steve Atkins a écrit :
>>
>>> If I have a partitioned table that has some range constraints that look kinda like they're intended for constraint
exclusion,but aren't quite non-overlapping, will that break anything? 
>>>
>>> e.g.
>>>
>>> create table jan ( …, check(created >= '2013-01-01' and created < '2013-02-01'), check(id >=0 and id < 10000100) )
inherits(foo);
>>> create table feb ( …, check(created >= '2013-02-01' and created < '2013-03-01'), check(id >=1000000 and id <
20000100)) inherits(foo); 
>>> create table mar ( …, check(created >= '2013-03-01' and created < '2013-04-01'), check(id >=2000000 and id <
30000100)) inherits(foo); 
>>>
>>> Querying by created should be fine, and take advantage of constraint exclusion, but will querying by id work? And
ifit does work, will it take any advantage of those constraints at all, or just search all the child partitions? 
>>
>> I don't know, but I suspect a quick EXPLAIN ANALYZE will tell you, even with empty tables.
>
> Explain suggests it'll work fine, and make good use of the constraints to prune partitions from the plan. But the
docsare pretty specific about overlapping range constraints being a bad thing so I'm wondering if there's potential for
problems.


For values that are in the overlapping parts of the partition, the database will have to look in both table partitions
tofind a record that you're searching for instead of a single table partition. That partially defeats the purpose of
usingexclusion constraints. 

Next to that, putting data in the tables becomes ambiguous for records that match both constraints - in which table
shouldthe records go? That is something that you need to do programatically anyway, so with the knowledge of how to
decidewhich records go where, you could also define your exclusion constraints to not be ambigous. 

I don't see any benefit of having ambiguous exclusion constraints - IMHO you're better off fixing them.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



pgsql-general by date:

Previous
From: Steve Atkins
Date:
Subject: Re: Constraint exclusion and overlapping range checks
Next
From: Raymond O'Donnell
Date:
Subject: Re: [pgeu-general] Call for design: PostgreSQL mugs