From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Effects of GUC settings on automatic replans |
Date: | 2007-04-09 20:39:24 |
Message-ID: | 09D87436-9EE8-4A95-AB45-B5375173D3ED@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 25, 2007, at 12:31 PM, Tom Lane wrote:
> Jim Nasby <decibel(at)decibel(dot)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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2007-04-09 20:48:34 | Re: Changing semantics of autovacuum_cost_limit |
Previous Message | Bruce Momjian | 2007-04-09 20:16:10 | Re: UTF8MatchText |