Ü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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to