On Mar 25, 2007, at 12:31 PM, Tom Lane wrote:
> Jim Nasby <decibel@decibel.org> 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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)