Статистика по времени запроса (PostgreSQL)

У меня есть таблица с миллиардом строк, и я хотел бы определить среднее время и стандартное отклонение времени для нескольких запросов формы:

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 (т.е. я не хочу писать внешнюю программу, чтобы сделать это).

7
задан Donald Miner 1 July 2010 в 18:03
поделиться

2 ответа

Знаете ли вы об операторе EXPLAIN ?

Эта команда отображает план выполнения, который планировщик PostgreSQL создает для предоставленного оператора. План выполнения показывает, как будут сканироваться таблицы, на которые ссылается оператор - обычным последовательным сканированием, сканированием индекса и т.д. таблица ввода.

Самая важная часть отображения - это оценочная стоимость выполнения оператора, которая является предположением планировщика о том, сколько времени потребуется для выполнения оператора (измеряется в единицах выборки страниц на диске). Фактически показаны два числа: время запуска до того, как первая строка может быть возвращена, и общее время для возврата всех строк. Для большинства запросов важно общее время, но в таких контекстах, как подзапрос в EXISTS, планировщик выберет наименьшее время запуска вместо наименьшего общего времени (так как в любом случае исполнитель остановится после получения одной строки). Кроме того, если вы ограничиваете количество возвращаемых строк с помощью предложения LIMIT, планировщик выполняет соответствующую интерполяцию между затратами конечной точки, чтобы оценить, какой план действительно самый дешевый.

Параметр ANALYZE вызывает фактическое выполнение оператора, а не только его планирование.Общее время, затраченное на каждый узел плана (в миллисекундах), и общее количество фактически возвращенных строк добавляются к отображению. Это полезно для того, чтобы узнать, близки ли оценки планировщика к реальности.

Можно довольно легко написать сценарий, который выполняет EXPLAIN ANALYZE по вашему запросу для каждого из случайных значений в таблице и сохраняет вывод в файл / таблицу / и т. Д.

6
ответ дан 6 December 2019 в 09:18
поделиться

Вам необходимо изменить файл конфигурации 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 .

12
ответ дан 6 December 2019 в 09:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: