Re: Performance of query (fwd)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Tkach <dmitry(at)openratings(dot)com>
Cc: Dann Corbit <DCorbit(at)connx(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Performance of query (fwd)
Date: 2003-06-11 16:55:11
Message-ID: 19933.1055350511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dmitry Tkach <dmitry(at)openratings(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-06-11 16:58:34 Re: Performance of query (fwd)
Previous Message Forest Wilkinson 2003-06-11 16:52:48 Re: How to enumerate foreign key constraints after migrating from 7.1.3?