Re: Effects of GUC settings on automatic replans

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)

In response to

Responses

Browse pgsql-hackers by date

  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