Я имел в виду только то, что реальное время выполнения запроса в production (где много других backends) может быть существенно больше времени его выполнения в тестовой среде с hardware 1:1 и холодным кешем, но где этот запрос только один.

именно, все одинаковое, включае расположение данных блоат и тд (тк получен из теплого стендбая промоутом)

ясно (с)

Ну так примерно прикинуть можно (с точностью до порядка, если нагрузку знать), но если "насыщения по CPU RAM IO нет", то расчёты по холодному кешу не имеют отношения к делу в любом случае, нет?

есть запрос он длится 100 секунд, сеплированием ожиданий получаем что на чтение ушло 20 секунд, остальные 80 на СPU.  На проде (тк мы приняли как предположение нет проблем с CPU IO RAM)  теже 80 секунд уйдтут на CPU, а вот сколько уйдет на чтение? 20 или 2000 секунд? Это зависит от того сколько нужных дынных на тесте мы причитали с диска а сколько из кеша (кеш ОС не трогаем пока для простоты)

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

возможно ваша задача решается с помощью dynamic tracing,
там есть пробки которые относятся к работе с буфером и блоком, например buffer-*, smgr-md-*. Возможно можно как-то извлечь нужную инфу, но это придется отдельно анализировать значения ForkNumber/BlockNumber.
Еще аналогичный вариант через eBPF и отслеживание постгресовых функций.
Если вдруг напишите такую тулзу, обязательно выложите в опенсорс.

я понимаю, да. таблица может в 100 увеличиться и план может поменяться, но если у нас довольно большая и стабильная система без взрывных ростов, внезапных блоатов и тд, и хочется с помощью тестового сервака оценить время некоторых запросов

спасибо!

> сеплированием ожиданий получаем что на чтение ушло 20 секунд, остальные 80 на СPU.  

Если Вы хотите начать с холодного кеша, и игнорировать кеш ОС, то это время можно извлечь (с поправкой на overhead explain, он обычно небольшой) хоть из EXPLAIN ANALYZE.

> (тк мы приняли как предположение нет проблем с CPU IO RAM)

Которое по определению неверно? Неплохая основа. ;)
Если что, оно неверно потому, что один запрос (backend) вполне способен загрузить кое-какие диски полностью, и если параллельно хоть кто-то что-то читает — это значит, что "их" время добавляется к данному запросу.

> а вот сколько уйдет на чтение? 20 или 2000 секунд?

См. выше. Т.е. "как повезёт", и почему Вы предполагаете, что это всё стартует с холодного кеша, я всё не могу понять?

я не предполагаю что стартует с холодного кеша, я хотел сказать, что имеющимися средствами не получается понять сколько блоков нужно для выполнения запроса. у нас есть shared_blks_hit  и shared_blks_read.    shared_blks_hit =100 в случае холодного могут означать  shared_blks_read=100  а могут shared_blks_read=1 если один и тот же блок в кеше читался для нужд запроса 100 раз. И мой вопрос был какбы нам это определить

если у нас быстрые ссд диски нет очереди запросов к диску то появление еще одного бекенда читающего с него не повысит латенси

> появление еще одного бекенда читающего с него не повысит латенси
ну тут как повезет, смотря какой запрос в бэкенд прилетит

Нет, на холодном кеше они означают именно то, что надо (опять-таки, при учёте "нет проблем с CPU IO RAM").

оказывается это известный баг: https://stackoverflow.com/questions/51673254/pg-restore-clean-removes-access-to-schema-public

Написал небольшой тест, который производит выгрузку тестовой базы в дамп в разных режимах, после каждого теста рестартовал постгрес и скидывал кэш операционной системы. Где-то ближе к концу своего скрипта словил ошибку:
Job for postgresql-13.service failed because start of the service was attempted too often. See "systemctl status postgresql-13.service" and "journalctl -xe" for details.

В journalctl и в status postgresql-13.service были такие строки:
Feb 18 18:54:31 centos_base systemd[1]: start request repeated too quickly for postgresql-13.service
Feb 18 18:54:31 centos_base systemd[1]: Failed to start PostgreSQL 13 database server.

Настройки в юнит-файле не трогал. Куда рыть, чтобы избавиться от ошибки?

пока нагуглил, что StartLimitIntervalSec можно сделать равным 0.

Привет всем, как решить эту проблему?

День добрый! Скажите, при ошибке такого вида:

sqlErrorMsg = "malformed array literal: \"[1,2,9]\"", sqlErrorDetail = "Missing \"]\" after array dimensions."

означает, что psql не может прочитать формат данных вида [1,2,9] или дело в чем то другом?

Спасибо

Коллеги, привет, глупый вопрос, может я не туда смотрю или разучился читать.
Смотрю в доки по 11 версии про avtovacuum daemon:
therwise, if the number of tuples obsoleted since the last VACUUM exceeds the “vacuum threshold”, the table is vacuumed

Вот это "number of tuples"  - это что? n_mod_since_analyze из pg_stat_all_tables?