У меня есть таблица с миллиардом строк, и я хотел бы определить среднее время и стандартное отклонение времени для нескольких запросов формы:
select * from mytable where col1 = '36e2ae77-43fa-4efa-aece-cd7b8b669043';
select * from mytable where col1 = '4b58c002-bea4-42c9-8f31-06a499cabc51';
select * from mytable where col1 = 'b97242ae-9f6c-4f36-ad12-baee9afae194';
....
У меня есть тысяча случайных значений для col1, сохраненного в другой таблице.
Там некоторый путь состоит в том, чтобы сохранить, сколько времени каждый из этих запросов взял (в миллисекундах) в отдельной таблице, так, чтобы я мог выполнить некоторую статистику по ним? Что-то как: для каждого col1 в моей случайной таблице выполните запрос, запишите время, затем сохраните его в другой таблице.
Совершенно другой подход был бы прекрасен, пока я могу остаться в PostgreSQL (т.е. я не хочу писать внешнюю программу, чтобы сделать это).
Знаете ли вы об операторе EXPLAIN
?
Эта команда отображает план выполнения, который планировщик PostgreSQL создает для предоставленного оператора. План выполнения показывает, как будут сканироваться таблицы, на которые ссылается оператор - обычным последовательным сканированием, сканированием индекса и т.д. таблица ввода.
Самая важная часть отображения - это оценочная стоимость выполнения оператора, которая является предположением планировщика о том, сколько времени потребуется для выполнения оператора (измеряется в единицах выборки страниц на диске). Фактически показаны два числа: время запуска до того, как первая строка может быть возвращена, и общее время для возврата всех строк. Для большинства запросов важно общее время, но в таких контекстах, как подзапрос в EXISTS, планировщик выберет наименьшее время запуска вместо наименьшего общего времени (так как в любом случае исполнитель остановится после получения одной строки). Кроме того, если вы ограничиваете количество возвращаемых строк с помощью предложения LIMIT, планировщик выполняет соответствующую интерполяцию между затратами конечной точки, чтобы оценить, какой план действительно самый дешевый.
Параметр
ANALYZE
вызывает фактическое выполнение оператора, а не только его планирование.Общее время, затраченное на каждый узел плана (в миллисекундах), и общее количество фактически возвращенных строк добавляются к отображению. Это полезно для того, чтобы узнать, близки ли оценки планировщика к реальности.
Можно довольно легко написать сценарий, который выполняет EXPLAIN ANALYZE
по вашему запросу для каждого из случайных значений в таблице и сохраняет вывод в файл / таблицу / и т. Д.
Вам необходимо изменить файл конфигурации PostgreSQL.
Включите это свойство:
log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
# statements running at least this number
# of milliseconds
После этого время выполнения будет регистрироваться, и вы сможете точно определить, насколько плохо (или хорошо) выполняются ваши запросы.
Вы также можете использовать некоторые утилиты LOG PARSING, чтобы обеспечить отличный HTML-вывод для дальнейшего анализа, например pgfouine .