Re: IMMUTABLE?

Поиск
Список
Период
Сортировка
От David Wheeler
Тема Re: IMMUTABLE?
Дата
Msg-id 719F1E6C-4695-4FD2-A73B-0E3AE173B8F0@kineticode.com
обсуждение исходный текст
Ответ на Re: IMMUTABLE?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: IMMUTABLE?  (Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>)
Список pgsql-performance
On May 15, 2006, at 21:31, Tom Lane wrote:

> Sure.  As I read it, that's talking about a static transformation:
> planner sees 2 + 2 (or if you prefer, int4pl(2,2)), planner runs the
> function and replaces the expression with 4.  Nothing there about
> memoization.

Oh, I see. So it's more like a constant or C macro.

> It's true that the system *could* memoize (or in our more usual
> parlance, cache function values) given the assumptions embodied in
> IMMUTABLE.  But we don't, and I don't see any statement in the docs
> that promises that we do.  For 99% of the functions that the planner
> deals with, memoization would be seriously counterproductive because
> the function evaluation cost is comparable to if not less than the
> lookup cost in a memo table.  (int4pl is a good case in point.)

Yes, but there are definitely programming cases where memoization/
caching definitely helps. And it's easy to tell for a given function
whether or not it really helps by simply trying it with CACHED and
without.

Would this be a simple thing to implement?

Best,

David

В списке pgsql-performance по дате отправления:

Предыдущее
От: Joachim Wieland
Дата:
Сообщение: Re: IMMUTABLE?
Следующее
От: Arjen van der Meijden
Дата:
Сообщение: Re: Pgsql (and mysql) benchmark on T2000/Solaris and some