Ü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