Re: "Constraint exclusion" is not general enough - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: "Constraint exclusion" is not general enough
Date
Msg-id 1154718911.2926.20.camel@localhost.localdomain
Whole thread Raw
In response to "Constraint exclusion" is not general enough  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ühel kenal päeval, R, 2006-08-04 kell 14:40, kirjutas Tom Lane:
> I was just looking at Martin Lesser's gripe here:
> http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
> about how the planner is not real bright about the filter conditions
> it generates for a simple partitioning layout.  In particular it's
> generating scans involving self-contradictory conditions:
> 
>  Result  (cost=0.00..33.20 rows=6 width=36)
>    ->  Append  (cost=0.00..33.20 rows=6 width=36)
>          ->  Seq Scan on t_parted  (cost=0.00..33.20 rows=6 width=36)
>                Filter: ((id1 >= 0) AND (id1 < 100) AND (id1 >= 900) AND (id1 < 1000))
> 
> which it seems we ought to be bright enough to notice.  In particular
> I would argue that turning on constraint_exclusion ought to instruct
> the planner to catch this sort of thing, whereas when it's off we
> ought not expend the cycles.  I have a preliminary patch (below)
> that seems to fix it.
> 
> The problem I'm having is that this isn't "constraint exclusion" anymore
> --- it will in fact make useful deductions without a table constraint
> anywhere in sight. 

I'd just keep the name. the parts of WHERE cluse can be described as
constraints on what is returned :)


-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 8.2 features status
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] extension for sql update