Comments 7
Ох, тяжело читать это всё. Ничего не понятно пока не перейдёшь по ссылкам на Дзен чтобы, хотя бы, сами запросы увидеть.
А сколько строк в каждой таблице? А план запроса - это что - просто "EXPLAIN", а не "EXPLAIN ANALYZE"?
В первом сценарии вам особо первичный ключ и не нужен - вы просто читаете все строки из pgbench_branches и присоединяете pgbench_accounts, на которой как раз ключ-то есть и используется для поиска.
Во втором сценарии только один из 4 запросов использует branches.
В третьем сценарии branches вообще не используется, вы вставляете в pgbench_history.
В каждой процедуре вы сначала отдельными запросами вычисляете минимум-максимум из таблицы, а потом ещё отдельно запрос в саму таблицу. И эта процедура у вас дёргается как нагрузка? Мда... Что за ерунда происходит вообще?
И какой же вывод вы делаете из всего этого? Лучше потому что что? Так может удалить первичные ключи из pgbench_accounts и остальных таблиц тоже?
И какой вывод? Почему мы получаем такие результаты? 8 ядер cpu это я типа в DNS пришел или что?
Для статьи тут как будто не хватает размышлений (вступление и предпосылки, описание попыток разобраться, выводы и советы).
Для сухих замеров тут тоже много чего не хватает. Собственно подробностей (самих запросов, описания железа, других сценариев).
После прочтения осталось очень неприятное впечатление. Словно автор сделал.. что-то, без цели, плана и методики, сам не до конца понимая что.. получил какие-то результаты.. не видит возможности сделать на основании этих результатов ну хоть какой-то вывод..
А статью разместить нужно, даже необходимо - причём срочно.
Так и не понял, так, когда же первичный ключ становится узким местом?
По ссылке 7 «Операционная скорость - сумма завершенных SQL операций и числа строк полученных или затронутых оператором за промежуток времени». Без индекса при полном сканировании «затрагиваются» все строки таблицы, операционная скорость взлетает до небес, а реального эффекта TPS нет. Складывать число запросов с числом затронутых строк (мягко и тепло говоря) оригинально.
Не нашёл что такое «точка наблюдения».
Операционная скорость - сумма завершенных SQL операций и числа строк полученных или затронутых оператором за промежуток времени
Операционная скорость
Как было указано выше, для расчета операционной скорости необходимы следующие исходные данные:
1) Количество выполненных запросов за отрезок времени.
2) Количество обработанных или изменённых строк за отрезок времени.
[11] pgpro_stats
Для получения необходимых для расчетов данных используются представления расширения pgpro_stats:
1)Представление pgpro_stats_statements
Статистика, собираемая модулем, выдаётся через представление с именем pgpro_stats_statements. Это представление содержит отдельные строки для каждой комбинации идентификатора базы данных, идентификатора пользователя и идентификатора запроса.[1]
2)Представление pgpro_stats_totals
Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals. Это представление содержит отдельные строки для каждого отдельного объекта БД[2]
Используемые столбцы:
· calls Счётчик выполнений данного оператора
· rows Общее число строк, полученных или затронутых оператором
Данные собираются по СУБД в целом (pgpro_stats_totals) и по каждому SQL (pgpro_stats_statements) в отдельности.
Периодичность сбора = 1 минута.
Источник: https://dzen.ru/a/aGYjGIt_KDOjmf35
Таким образом, для расчета операционной скорости используется терминология из описания представления pgpro_stats :
calls Счётчик выполнений данного оператора
rows Общее число строк, полученных или затронутых оператором
Postgres Pro Enterprise : Документация: 15: G.5. pgpro_stats : Компания Postgres Professional
Хотя , в расширении pg_expecto не используется pgpro_stats( в отличии от комплекса pg_hazel), терминология принципиально не отличается.
Точка наблюдения
Периодичность сбора данных для статистического анализа (медианное сглаживание и агрегация) = 1 минута. Таким образом - Точка наблюдения это номер минуты в ходе теста.
Обратная сторона индекса: когда первичный ключ становится узким местом