Postgresql время выполнения запроса

Postgresql время выполнения запроса

Я не могу получить время запроса. Вместо этого я получаю следующую ошибку:

Для целей тестирования вы также можете использовать EXPLAIN ANALYZE .

Вы можете использовать его так, чтобы проверить, действительно ли моя адаптированная версия вашего запроса быстрее:

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

PostgreSQL не является Transact-SQL. Это две разные вещи.

В PostgreSQL это будет нечто вроде строк

С другой стороны, измерение времени запроса не обязательно должно быть таким сложным.

Во-первых, в клиент командной строки postgres у вас есть функция iming , которая измеряет время запроса на стороне клиента (аналогично длительности в правом нижнем углу SQL Server Management Studio).

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

В-третьих, возможно собрать временные интервалы на сервере для любого отдельного оператора с помощью EXPLAIN :

EXPLAIN — показать план выполнения оператора

Синтаксис

Описание

Эта команда выводит план выполнения, генерируемый планировщиком Postgres Pro для заданного оператора. План выполнения показывает, как будут сканироваться таблицы, затрагиваемые оператором — просто последовательно, по индексу и т. д. — а если запрос связывает несколько таблиц, какой алгоритм соединения будет выбран для объединения считанных из них строк.

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

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

Читайте также:  Pioneer deh 4300ub инструкция

Важно

Имейте в виду, что с указанием ANALYZE оператор действительно выполняется. Хотя EXPLAIN отбрасывает результат, который вернул бы SELECT , в остальном все действия выполняются как обычно. Если вы хотите выполнить EXPLAIN ANALYZE с командой INSERT , UPDATE , DELETE , CREATE TABLE AS или EXECUTE , не допуская изменения данных этой командой, воспользуйтесь таким приёмом:

Без скобок для этого оператора можно указать только параметры ANALYZE и VERBOSE и только в таком порядке. В PostgreSQL до версии 9.0 поддерживался только синтаксис без скобок, однако в дальнейшем ожидается, что все новые параметры будут восприниматься только в скобках.

Параметры

Выполнить команду и вывести фактическое время выполнения и другую статистику. По умолчанию этот параметр равен FALSE . VERBOSE

Вывести дополнительную информацию о плане запроса. В частности, включить список столбцов результата для каждого узла в дереве плана, дополнить схемой имена таблиц и функций, всегда указывать для переменных в выражениях псевдоним их таблицы, а также выводить имена всех триггеров, для которых выдаётся статистика. По умолчанию этот параметр равен FALSE . COSTS

Вывести рассчитанную стоимость запуска и общую стоимость каждого узла плана, а также рассчитанное число строк и ширину каждой строки. Этот параметр по умолчанию равен TRUE . BUFFERS

Включить информацию об использовании буфера. В частности, вывести число попаданий, блоков прочитанных, загрязненных и записанных в разделяемом и локальном буфере, а также число прочитанных и записанных временных блоков. Попаданием считается ситуация, когда требуемый блок уже находится в кеше и чтения с диска удаётся избежать. Блоки в общем буфере содержат данные обычных таблиц и индексов, в локальном — данные временных таблиц и индексов, а временные блоки предназначены для краткосрочного использования при выполнении сортировки, хеширования, материализации и подобных узлов плана. Число загрязнённых блоков показывает, сколько ранее не модифицированных блоков изменила данная операция; тогда как число записанных блоков показывает, сколько ранее загрязнённых блоков данный серверный процесс вынес из кеша при обработке запроса. Значения, указываемые для узла верхнего уровня, включают значения всех его дочерних узлов. В текстовом формате выводятся только ненулевые значения. Этот параметр действует только в режиме ANALYZE . По умолчанию его значение равно FALSE . TIMING

Читайте также:  Pi seek pioneer что это

Включить в вывод фактическое время запуска и время, затраченное на каждый узел. Постоянное чтение системных часов может значительно замедлить запрос, так что если достаточно знать фактическое число строк, имеет смысл сделать этот параметр равным FALSE . Время выполнения всего оператора замеряется всегда, даже когда этот параметр выключен и на уровне узлов время не подсчитывается. Этот параметр действует только в режиме ANALYZE . По умолчанию его значение равно TRUE . FORMAT

Установить один из следующих форматов вывода: TEXT, XML, JSON или YAML. Последние три формата содержат ту же информацию, что и текстовый, но больше подходят для программного разбора. По умолчанию выбирается формат TEXT . boolean

Включает или отключает заданный параметр. Для включения параметра можно написать TRUE , ON или 1 , а для отключения — FALSE , OFF или 0 . Значение boolean можно опустить, в этом случае подразумевается TRUE . оператор

Любой оператор SELECT , INSERT , UPDATE , DELETE , VALUES , EXECUTE , DECLARE , CREATE TABLE AS и CREATE MATERIALIZED VIEW AS , план выполнения которого вас интересует.

Выводимая информация

Результатом команды будет текстовое описание плана, выбранного для оператора , возможно, дополненное статистикой выполнения. Представленная информация описана в Разделе 14.1.

Замечания

Чтобы планировщик запросов Postgres Pro был достаточно информирован для эффективной оптимизации запросов, данные в pg_statistic должны быть актуальными для всех таблиц, задействованных в запросе. Обычно об этом автоматически заботится демон автоочистки. Но если в таблице недавно произошли значительные изменения, может потребоваться вручную выполнить ANALYZE , не дожидаясь, пока автоочистка обработает эти изменения.

Измеряя фактическую стоимость выполнения каждого узла в плане, текущая реализация EXPLAIN ANALYZE привносит накладные расходы профилирования в выполнение запроса. В результате этого, при запуске запроса командой EXPLAIN ANALYZE он может выполняться значительно дольше, чем при обычном выполнении. Объём накладных расходов зависит от природы запроса, а также от используемой платформы. Худшая ситуация наблюдается для узлов плана, которые сами по себе выполняются очень быстро, и в операционных системах, где получение текущего времени относительно длительная операция.

Читайте также:  Айфон 7 расцветки фото

Примеры

Получение плана простого запроса для таблицы, содержащей единственный столбец типа integer , с 10000 строк:

План того же запроса, но выведенный в формате JSON:

Если в таблице есть индекс, а в запросе присутствует условие WHERE , для которого полезен этот индекс, EXPLAIN может показать другой план:

План того же запроса, но в формате YAML:

Рассмотрение формата XML оставлено в качестве упражнения для читателя.

План того же запроса без вывода оценок стоимости:

Пример плана для запроса с агрегатной функцией:

Пример использования EXPLAIN EXECUTE для отображения плана выполнения подготовленного запроса:

Разумеется, конкретные числа, показанные здесь, зависят от фактического содержимого задействованных таблиц. Также учтите, что эти числа и даже выбранная стратегия выполнения запроса могут меняться от версии к версии Postgres Pro вследствие усовершенствования планировщика. Кроме того, команда ANALYZE при обработке статистических данных производит случайные выборки, так что оценки стоимости могут меняться при каждом чистом запуске ANALYZE , даже когда фактическое распределение данных в таблице не меняется.

Совместимость

Оператор EXPLAIN отсутствует в стандарте SQL.

В интерфейсе командной строки MySQL , когда вы выполняете запрос, он сообщит вам, сколько времени потребовалось для выполнения запроса после распечатки. результаты.

В интерфейсе командной строки Postgres ( psql ) он не сообщает вам. Я знаю, как настроить ведение журнала, чтобы получить информацию из журналов, но было бы удобнее печатать ее в стандартный вывод, как это делается в MySQL

Можно ли это сделать?

2 ответа

Если вы хотите, чтобы время выполнения на стороне сервера не включало время передачи результата клиенту, вы можете установить log_min_duration_statement = 0 в конфигурации, затем SET client_min_messages = log , чтобы вы получили информацию журнала в консоли.

Вы также можете использовать EXPLAIN ANALYZE для получения подробных данных о времени выполнения. Для этого есть некоторые временные издержки, если только вы не используете EXPLAIN (ANALYZE TRUE, TIMING FALSE) , который есть только в более новых версиях, и отключает подробную синхронизацию, чтобы дать только совокупное время выполнения вместо этого.

PgBadger , особенно в сочетании с модуль auto_explain , может предоставить полезную статистическую статистику из анализа журнала.

Наконец, есть pg_stat_statements , которая может собирать удобные сводные данные в работающей системе.

Ссылка на основную публикацию
Adblock detector