История изменений

Для процедур тоже из кэша? Я не вникал внутрь pg, так что может чего-то не знаю. Суть в том, что pgpool это клиент для pg-server. Т.е. лишний элемент (уменьшает надежность, вносит свои баги и т.д.).

Ну и попроще пример: в очереди 100 одинаковых задач одна за другой идут последовательно, что сделает твой pgpool? Он сумеет понять, что все они одинаковые? Т.е. после получения ответа из БД он сразу вышлет 99 одинаковых ответов? Или всех прогонит через БД? А он так и сделает, т.к. pgpool архитектурно не встроен в БД, он не знает, что кроме него к БД подключен пользователь Петя, который на 55 задаче делает INSERT в эту же таблицу.

Что должно быть в идеале: БД видит это делает один прогон по таблице и моментально отдает ответ на остальные 99 задач. Если в середину попадет INSERT, допустим 42 по счету, то 1 запрос - читает из БД, далее до 41 идет чтение из кэша, потом INSERT, потом снова чтение, и далее из кэша до 100 задачи.

Разница в логике здесь не в том, что кэш/не кэш, а точно знать, когда и какой запрос выполняется, независимо от того сколько пользователей/сессий открыто и запускают запросы. Все, решает сама БД, когда оптимизировать, а когда нет. Из того что я помню, любой SELECT вешает на таблицу READONLY-блок, т.е., клиент даже на этапе формирования ответа при подании в ту же секунду INSERT вернет старое значение! А БД можно изменить так, что если ответ не сформирован и имеем INSERT, то сначала сделаем INSERT, а затем вернем конечный результат.

Для процедур тоже из кэша? Я не вникал внутрь pg, так что может чего-то не знаю. Суть в том, что pgpool это клиент для pg-server. Т.е. лишний элемент (уменьшает надежность, вносит свои баги и т.д.).

Ну и попроще пример: в очереди 100 одинаковых задач одна за другой идут последовательно, что сделает твой pgpool? Он сумеет понять, что все они одинаковые? Т.е. после получения ответа из БД он сразу вышлет 99 одинаковых ответов? Или всех прогонит через БД? А он так и сделает, т.к. pgpool архитектурно не встроен в БД, он не знает, что кроме него к БД подключен пользователь Петя, который на 55 задаче делает INSERT в эту же таблицу.

Что должно быть в идеале: БД видит это делает один прогон по таблице и моментально отдает ответ на остальные 99 задач. Если в середину попадет INSERT, допустим 42 по счету, то 1 запрос - читает из БД, далее до 41 идет чтение из кэша, потом INSERT, потом снова чтение, и далее из кэша до 100 задачи.