On Mar 25, 2007, at 12:31 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
constraint_exclusion
Hrm... wasn't that option added in case there was a bug in the
exclusion code?
Well, the "bug" was a lack of ways to get rid of plans that were
no longer valid because of constraint changes; a problem that no
longer exists now that the invalidation mechanism is there.
(Hm, I think the docs need some updates now...)
The other argument was that you might not want the costs of searching
for contradictory constraints if your workload was such that the
search
never or hardly ever succeeds. That still justifies the existence of
this GUC variable, I think, but I don't see that it's a reason to
force
replanning if the variable is changed. Certainly it's not any more
interesting than any of the other variables affecting planner
behavior.
I'm doubtful that there are any cases where not doing the search
would be worth the time saved, since it'd mean you'd be getting data
out of most/all partitions at that point...
If we are going to leave the GUC I think we should default it to ON.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
