АЛ
Пойду в доку. Чет засомневался
Size: a a a
2020 July 30
АЛ
pg_sleep - VOLATILE
АЛ
Может быть дело в этом?
КБ
Нет. Я пробовал заменить на простой кипятильник, эффект тот же. Пример кипятильника:
create function check_cache(par_id uuid) returns int
language plpgsql
immutable
as
$$
DECLARE
res int;
BEGIN
res = 0;
loop
exit when res > 10000000;
res = res + 1;
end loop;
RETURN res;
END;
$$;
create function check_cache(par_id uuid) returns int
language plpgsql
immutable
as
$$
DECLARE
res int;
BEGIN
res = 0;
loop
exit when res > 10000000;
res = res + 1;
end loop;
RETURN res;
END;
$$;
АЛ
Вообщем бегло пробежал доку
АЛ
КБ
Ну, тут они пишут наоборот, о том, что мутацию базы можно замаскировать, и получить в результате вероятные проблемы. У меня же наоборот: я не вижу, что кэш хотя бы раз использовался.
SB
Добрый день! Может кто-нибудь подсказать, как postgres решает, когда использовать кэшированное значение immutable-функции, а когда нужно вычислять. Параметры вызова всегда одни и те же. Ни разу не удалось наблюдать возврат кэшированного значения, функция всегда вычисляется. Может, настройку какую-то нужно включить? Воспроизводится на простейшей функции, например:
create function check_cache(id uuid) returns int
as 'select 222 from pg_sleep(5);' language sql immutable;
Вызываю с одним и тем же параметром, например:
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
Результат функции всегда один и тот же, но кэширование не срабатывает, и каждый вызов спит 5 сек.
create function check_cache(id uuid) returns int
as 'select 222 from pg_sleep(5);' language sql immutable;
Вызываю с одним и тем же параметром, например:
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
select check_cache('c9a77d55-d664-415f-bac0-c49701018b07');
Результат функции всегда один и тот же, но кэширование не срабатывает, и каждый вызов спит 5 сек.
в postgres нет кеша значений функций
АЛ
Я по этому и написал - Дело не в этом
АЛ
Но нигде не встретил упоминания, что postgres хоть как-то кэширует результат. Только, что оптимизатор принимает решение вычислять значения 1 раз в рамках запроса - да. Но у вас 3 запроса и каждый раз оптимизатор принимает решение вычислить значение 1 раз )
КБ
Да, в том-то и дело. В документации сказано, что вызов immutable функции с теми же параметрами может быть заменён на известный результат без повторного вычисления. Но не сказано, как, когда и вообще, делает ли это оптимизатор.
IMMUTABLE indicates that the function cannot modify the database and always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.
IMMUTABLE indicates that the function cannot modify the database and always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.
АЛ
Возможно заготовочка - для лучших времен. Когда кэширование результата появится или оптимизатор станет умнее )
АЛ
Сейчас я принципиальной разницы по сравнению со STABLE с точки зрения оптимизатора не вижу
КБ
Ясно, мне тоже так показалось. Что ж, благодарю за поддержку!
V
Характеристики STABLE и IMMUTABLE мало различаются, когда речь идёт о простых интерактивных запросах, которые планируются и сразу же выполняются; не имеет большого значения, будет ли функция выполнена однократно на этапе планирования или в начале выполнения. Существенное различие проявляется, когда план сохраняется и многократно используется позже. Если функция помечена как IMMUTABLE, тогда как на самом деле она не является постоянной, она может быть сведена к константе во время планирования, так что при последующих выполнениях плана вместо неё будет использоваться неактуальное значение. Это опасно при использовании подготовленных операторов или языков функций, кеширующих планы (например, PL/pgSQL).
КБ
Это всё прочитано по несколько раз. Вопрос в том, как воспроизвести хит по кэшу?
V
Не по кэшу а по сохраненному плану. Разницу чувствуете?
SB
Да, в том-то и дело. В документации сказано, что вызов immutable функции с теми же параметрами может быть заменён на известный результат без повторного вычисления. Но не сказано, как, когда и вообще, делает ли это оптимизатор.
IMMUTABLE indicates that the function cannot modify the database and always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.
IMMUTABLE indicates that the function cannot modify the database and always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.
"with all-constant arguments" вряд ли можно трактовать как "with same arguments"
ну и в любом случае "может" не значит "будет"
ну и в любом случае "может" не значит "будет"
J
Добрый день,
Может кто-нибудь подсказать по вопросу ниже?
В PG 9.4 есть колонка jsonb. При этом структура jsonb динамична, набор тегов меняется, вложенность тоже. Задача: обновлять value определенного тега (его уровень вложенности определить можем). В 9.5 вижу jsonb_set функцию , а для 9.4 будут идеи?
Может кто-нибудь подсказать по вопросу ниже?
В PG 9.4 есть колонка jsonb. При этом структура jsonb динамична, набор тегов меняется, вложенность тоже. Задача: обновлять value определенного тега (его уровень вложенности определить можем). В 9.5 вижу jsonb_set функцию , а для 9.4 будут идеи?