Re: Strange behavior of function date_trunc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Strange behavior of function date_trunc
Дата
Msg-id 4158236.1620308688@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Strange behavior of function date_trunc  (Pavel Luzanov <p.luzanov@postgrespro.ru>)
Ответы Re: Strange behavior of function date_trunc  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Strange behavior of function date_trunc  (Pavel Luzanov <p.luzanov@postgrespro.ru>)
Список pgsql-general
Pavel Luzanov <p.luzanov@postgrespro.ru> writes:
> Does having an index allow the function value to be cached?

For an indexscan, the comparison value is evaluated once and used to
search the index.  The point of the "stable" marking is actually to
promise that this will give the same result as the naive interpretation
of a WHERE clause, ie that the WHERE expression is notionally evaluated
at every row.

This case is the reason we invented the "stable" attribute to begin
with.  People have since misinterpreted it as authorizing caching of
function results, but that's not what it was intended for.

> The second question. What is the reason for choosing an index scan?

Probably the planner is picking that precisely to reduce the number
of calls of the user-defined function.  Since you left the function's
cost as default, which for PL functions is 100x the default cost of
a built-in function, that could well be a large enough number to
change the plan choice.  (You could experiment with altering the
COST property to see where the plan changes.)

            regards, tom lane



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Chain Hashing
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Strange behavior of function date_trunc