Postgres Pro Standard Документація 9
pg_stat_statements надає можливість відстежувати статистику виконання сервером всіх операторів SQL.
Цей модуль потрібно завантажувати, додавши pg_stat_statements в shared_preload_libraries у файлі postgresql.conf , тому що йому потрібна додаткова пам'ять, що розділяється. Це означає, що для завантаження або вивантаження модуля необхідно перезапустити сервер.
Коли модуль pg_stat_statements завантажується, він відстежує статистику з усіх баз даних на сервері. Для отримання та обробки цієї статистики цей модуль надає подання pg_stat_statements та допоміжні функції pg_stat_statements_reset та pg_stat_statements . Ці об'єкти не доступні глобально, але їх можна встановити у певній базі даних, виконавши команду CREATE EXTENSION pg_stat_statements .
F.34.1. Подання pg_stat_statements
Статистика, що збирається модулем, видається через уявлення з ім'ям pg_stat_statements. Це подання містить окремі рядки для кожної комбінації ідентифікатора бази даних, ідентифікатора користувача та ідентифікатора запиту (але в кількості, що не перевищує максимальної кількості різних операторів, які можуть відстежувати модуль). Стовпці подання показані у Таблиці F.23.
Таблиця F.23. Стовпці pg_stat_statements
З міркувань безпеки звичайні користувачі не бачать текст SQL і queryid для запитів, виконаних іншими користувачами. Однак вони можуть бачити статистику, якщо до їх бази даних встановлено подання.
Заплановані запити (тобто SELECT , INSERT , UPDATE і DELETE ) об'єднуються в один запис у pg_stat_statements , коли вони мають ідентичні структури запитів згідно з внутрішнім обчисленим хешем. Зазвичай два запити будуть вважатися рівними за такогопорівнянні, якщо вони семантично рівнозначні, крім значень констант, які у запиті. Проте службові команди (тобто й інші команди) порівнюються суворо по текстовим рядкам запитів.
Коли значення константи ігнорується для порівняння запиту з іншими запитами, ця константа замінюється у виведенні pg_stat_statements знаком ? . В іншому цей висновок містить текст першого запиту, що має певне значення хеша queryid, пов'язане із записом в pg_stat_statements.
У деяких випадках запити з візуально різними текстами можуть бути об'єднані в один запис pg_stat_statements. Зазвичай це відбувається тільки для семантично рівнозначних запитів, але є невелика ймовірність, що через накладення хешу незв'язані запити можуть бути об'єднаними в одному записі. (Проте це неможливо для запитів, що належать різним користувачам баз даних.)
Так як значення хешу queryid обчислюється за уявленнями запиту на стадії після розбору, можлива і зворотна ситуація: запити з однаковим текстом можуть опинитися в різних записах, якщо вони отримали різні уявлення з різних причин, наприклад, зміни search_path .
Споживачі статистики pg_stat_statements можуть побажати використовувати як більш стабільний і надійний ідентифікатор для кожного запису не текст запиту, а queryid (можливо, у поєднанні з dbid і userid ). Однак важливо розуміти, що стабільність значення хеша queryid гарантується з обмеженнями. Так як цей ідентифікатор виходить з дерева запиту після аналізу, його значення буде, крім іншого, залежатиме від внутрішніх ідентифікаторів об'єктів, що фігурують у цьому поданні. Із цим пов'язано кілька неінтуїтивних наслідків. Наприклад, pg_stat_statements вважатимедва однакових запити різними, якщо вони звертаються до таблиці, яка була видалена, а потім відтворена між цими запитами. Результат хешування також чутливий до відмінностей машинної архітектури та інших особливостей платформи. Більше того, не варто розраховувати на те, що queryid залишатиметься незмінним при оновленні основних версій Postgres Pro.
Як правило, значення queryid можна вважати надійними та порівнянними, лише за умови, що версія сервера та деталі метаданих каталогу незмінні. Отже, можна очікувати, що два сервера, що беруть участь у реплікації на основі відтворення фізичного WAL, матимуть однакові queryid для одного запиту. Однак схеми з логічною реплікацією не гарантують збереження ідентичності реплік у всіх деталях, що мають значення, так що queryid не буде корисним ідентифікатором для накопичення показників вартості за набором логічних реплік. У разі сумнівів у тому чи іншому підході рекомендується безпосередньо протестувати його.
Текст, що представляє запит, зберігається в зовнішньому файлі на диску і не займає пам'ять, що розділяється. Тому навіть дуже об'ємний текст запиту може бути успішно збережений. Однак, якщо у файлі накопичується багато довгих текстів запитів, він може зрости до незручного розміру. Як вирішення цієї проблеми, pg_stat_statements може вирішити стерти текст запитів, і в результаті у всіх існуючих записах у поданні pg_stat_statements в полі query будуть значення NULL, хоча статистика, пов'язана з кожним queryid буде збережена. Якщо це відбувається та заважає аналізу, можливо, варто зменшити pg_stat_statements.max для запобігання таким ситуаціям.
F.34.2. Функції
pg_stat_statements_reset очищає всю статистику, зібрануна той час модулем pg_stat_statements . За промовчанням цю функцію можуть виконувати лише суперкористувачі. pg_stat_statements(showtext boolean) returns setof record
Подання pg_stat_statements реалізовано з урахуванням функції, яка також називається pg_stat_statements . Клієнти можуть викликати функцію pg_stat_statements безпосередньо, і можуть вказати showtext := false і отримати результат без тексту запиту (тобто вихідний аргумент ( OUT ), відповідний стовпцю уявлення query , міститиме NULL). Ця можливість призначена для підтримки зовнішніх інструментів, котрим бажано уникнути витрат, пов'язаних із отриманням текстів запитів невизначеної довжини. Такі інструменти можуть кешувати текст першого запиту, який вони отримають самостійно, як це робить pg_stat_statements , а потім запитувати тексти запитів тільки при необхідності. Оскільки сервер зберігає тексти запитів у файлі, цей підхід скорочує обсяг фізичного вводу/виводу, що породжується при постійному зверненні даних pg_stat_statements .