Re: Performance of query (fwd) - Mailing list pgsql-general

From Tom Lane
Subject Re: Performance of query (fwd)
Date
Msg-id 19933.1055350511@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance of query (fwd)  (Dmitry Tkach <dmitry@openratings.com>)
Responses Re: Performance of query (fwd)
List pgsql-general
Dmitry Tkach <dmitry@openratings.com> writes:
> Tom Lane wrote:
>> I've thought about that ... but am not sure whether it wouldn't create
>> as many problems as it solves.  What are the consequences when the
>> planner's pre-evaluation yields a different result from what actually
>> happens at runtime?  Hardly an unlikely scenario when dealing with
>> stuff like now().

> But isn't now() supposed to return the same value within the same
> transaction?

What's that have to do with it?  Plans have to be good for longer than
one transaction --- see prepared statements and plpgsql plan caching.

> I must be missing something here - isn't it enough to use the same logic
> as when deciding whether the function output can be usedfor index scan?

No, see above.  If we could, we'd not have bothered to make a
distinction between IMMUTABLE and STABLE functions, we'd just allow the
planner to fold them all to constants at plan time.  (STABLE functions
aren't actually guaranteed to hold still even across one transaction,
only across one command in a transaction.  But that's not really
relevant to the planner's problem.)

            regards, tom lane

pgsql-general by date:

Previous
From: Forest Wilkinson
Date:
Subject: Re: How to enumerate foreign key constraints after migrating from 7.1.3?
Next
From: Tom Lane
Date:
Subject: Re: Performance of query (fwd)