А размером можно управлять? Попробовал - сохраняется только 16 запросов и, как мне кажется, при превышении 16 выкидывается из кэша не самый первый из добавленных, а самый последний:

execute block as
declare variable i integer;
declare variable tmp integer;
begin
  i = 1;
  while (i < 100) do
  begin
    execute statement('select '||i||' from rdb$database') into tmp;
    i = i + 1;
  end
end

MON$STATEMENTS:

select 1 from rdb$database
select 2 from rdb$database
....
select 15 from rdb$database
select 99 from rdb$database

Размером управлять можно, это есть в документации.
Но тест не годится, т.к. механизм EXEC STMT имеет свой встроенный небольшой (16шт) кеш препарированных запросов.

ggreggory, ты какую хрень проверяешь. Содержимое кеша подготовленных запросов надо смотреть в MON$COMPILED_STATEMENTS, а не в MON$STATEMENTS

Т.обр., пока что схема, реализованная в фибах, представляется более оптимальной: в фибах нет нужды всякий раз отправлять текст запроса на сервер. Конечно, возможно, я что-то упустил.

А ещё будут забавные глюки если FIB-ы попытаются препарированный запрос использовать в другом коннекте.

А фибы так не делают.

Моё мнение такое. Кеш препарированных запросов на стороне клиента не нужен. Держать подготовленными надо только запросы которые часто используются.
То есть если подготовленный запрос поработал, и закончил свою работу, и потом хрен знает когда опять использоваться будет (может через 5 минут,, может через час), то
не фиг держать его в каком-то кеше на клиенте. Пусть сервер с ним разбирается, он хотя бы может выкинуть его из кеша когда-нибудь.

Можно конечно его где-то кешировать, но это сильно усложнит архитектуру приложения, ибо такой кеш должен быть глобальным и привязан к коннекту.

К тому же он сделан с прицелом на будущее, когда в SS он будет общим, польза от него сильно увеличится.

Другое дело, что в текущем виде для некоторых приложений он бесполезен. Например на PHP. Коннект всё равно помрёт после выполнения PHP скрипта, а значит и его кеш.
Как известно в PHP нет пула коннектов к БД, а использование альтернативы в виде pconnect ни к чему хорошему не приведёт.

...
На практике кэширование крайне редко имеет смысл.

И еще когда кэш execute statement объединят с кэшем обычных запросов. Это тоже важно.

Цитата:

И еще когда кэш execute statement объединят с кэшем обычных запросов. Это тоже важно.

мне кажется ты не понимаешь что пишешь. В ES кеш совсем для других целей. И не может быть он тем же самым ибо есть ещё ES ON EXTERNAL

Моё мнение такое. Кеш препарированных запросов на стороне клиента не нужен. Держать подготовленными надо только запросы которые часто используются.
То есть если подготовленный запрос поработал, и закончил свою работу, и потом хрен знает когда опять использоваться будет (может через 5 минут,, может через час), то
не фиг держать его в каком-то кеше на клиенте. Пусть сервер с ним разбирается, он хотя бы может выкинуть его из кеша когда-нибудь.

Но есть и другие виды приложений. И некоторые написаны с использованием клиентского пула коннектов в парадигме - взял коннект из пула,

Такие приложения не могут организовать собственный набор препарированных запросов. В принципе,
это можно организовать на уровне используемого фреймворка, который реализует пул коннектов, но я про такие не слышал (может они и есть).
Так вот - для таких приложений кеш запросов на сервере очень даже может помочь. И реально помогает.

hvlad писал(а) Fri, 26 January 2024 11:51

Но есть и другие виды приложений. И некоторые написаны с использованием клиентского пула коннектов в парадигме - взял коннект из пула,

пользователь, роль, контексты - учитывается при создании/пользовании кешем?

hvlad писал(а) Fri, 26 January 2024 11:51

Такие приложения не могут организовать собственный набор препарированных запросов. В принципе,
это можно организовать на уровне используемого фреймворка, который реализует пул коннектов, но я про такие не слышал (может они и есть).
Так вот - для таких приложений кеш запросов на сервере очень даже может помочь. И реально помогает.

Тут ещё вопрос какие запросы вообще имеет смысл кэшировать. Нужно ли это делать для простых select/update/insert/delete? Каков будет для такого профит?

О чём вопрос ? Если о кеше запросов, то не вижу связи - кеш в рамках коннекта живёт.
Если о пуле коннектов - то это авторам оных пулов.

Моё мнение - кешировать имеет смысл те запросы, время на подготовку (prepare) которых составляет заметную часть времени выполнения.
Например, я знаю случай, когда элементарный INSERT препарировался менее чем 1 мс в монопольном коннекте, а под хорошей нагрузкой (десятки
параллельных потоков) - уже более 6 мс. И кеширование этого запроса очень заметно повлияло на масштабируемость всего приложения.

hvlad писал(а) Fri, 26 January 2024 13:37

Моё мнение - кешировать имеет смысл те запросы, время на подготовку (prepare) которых составляет заметную часть времени выполнения.
Например, я знаю случай, когда элементарный INSERT препарировался менее чем 1 мс в монопольном коннекте, а под хорошей нагрузкой (десятки
параллельных потоков) - уже более 6 мс. И кеширование этого запроса очень заметно повлияло на масштабируемость всего приложения.

Не совсем понятно что за случай такой. Если инсертов много, то программист должен сам использовать препарированные запросы.
Если инсертов мало, то и кешировать их нет смысла.
Если сервер очень сильно загружен, то кэширование это паллиатив.

Я выше писал про приложения с пулом коннектов.

hvlad писал(а) Tue, 30 January 2024 14:12

Я выше писал про приложения с пулом коннектов.

Ок. Я вижу только такой случай: высоконагруженное web приложение ипользующее пул коннектов. Когда много-много юзеров делают примерно одинаковый набор запросов.

Но опять же тут желателен единый кэш на все коннекты.

Привет всем.
Народ, подскажите, плиз, как теперь использовать RETURNING в FD в В12 ?

SergeyKNP писал(а) Wed, 28 February 2024 17:19

Привет всем.
Народ, подскажите, плиз, как теперь использовать RETURNING в FD в В12 ?

https://groups.google.com/g/firebird-support/c/el1di53Fjpg
https://en.delphipraxis.net/topic/11054-tfdupdatesql-problem /
Оно ?