Re: Performance of query (fwd)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance of query (fwd)
Дата
Msg-id 19933.1055350511@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Performance of query (fwd)  (Dmitry Tkach <dmitry@openratings.com>)
Ответы Re: Performance of query (fwd)  (Dmitry Tkach <dmitry@openratings.com>)
Список 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 по дате отправления:

Предыдущее
От: Forest Wilkinson
Дата:
Сообщение: Re: How to enumerate foreign key constraints after migrating from 7.1.3?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance of query (fwd)