Ü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? http://www.postgresql.org/docs/faq