Как получить точное измерение эффективности запроса? - PullRequest
1 голос
/ 02 марта 2012

Я сравниваю запросы в PostgreSQL 8.3.14, которые возвращают тот же набор результатов.

Я использовал EXPLAIN в своих запросах для отслеживания предполагаемой общей стоимости.Я также запускал запросы несколько раз и записывал общее время, необходимое для выполнения.Я понимаю, что последовательные запуски приведут к кешированию большего количества данных и искажут фактическое время работы без кэширования.

Тем не менее, я ожидаю, что стоимость EXPLAIN будет несколько пропорциональна общему времени выполнения (с перекосом кэша).

Мои данные это опровергают.Я сравнил 4 запроса.

  1. Запрос A
    • Общая стоимость: 119 500
    • Среднее время выполнения: 28,101 секунд
  2. Запрос B
    • Общая стоимость: 115 700
    • Среднее время выполнения: 28,291 секунды
  3. Запрос C
    • Общая стоимость: 116 200
    • Среднее время выполнения: 32,409 секунд
  4. Запрос D
    • Общая стоимость: 93 200
    • Среднее время выполнения: 37,503 секунд

В последний раз я запускал Query D, и, в любом случае, он должен быть самым быстрым из-за проблемы с кэшированием.Поскольку выполнение запросов без кеша кажется трудным на основании этого Q + A:

[SO]: видеть и очищать кеши / буферы Postgres?

Как я могуопределить, какой запрос является наиболее эффективным?

Ответы [ 2 ]

1 голос
/ 04 марта 2012

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

Эта информация может устареть. Если вы действительно пытаетесь получить точное представление о том, насколько дорогим является запрос, убедитесь, что статистика, используемая postgres, актуальна, выполнив оператор VACUUM ANALYZE.

Кроме того, планировщик вынужден сделать несколько сравнений яблок с апельсинами; каким-то образом сравнивая время, которое требуется для поиска, со временем, которое требуется для выполнения тесного цикла по отношению в памяти. Поскольку разные аппаратные средства могут выполнять эти операции с разными относительными скоростями, иногда, особенно для близких связей, postgres может ошибаться. Эти относительные затраты можно настроить в конфигурации файла конфигурации вашего сервера

Edit: Статистика, собранная postgesql, не относится к «производительности запросов» и не обновляется последовательными запросами. Они описывают только частоту и распределение значений в каждом столбце каждой таблицы (кроме случаев, когда они отключены). Наличие точной статистики важно для точного планирования запросов, но вы, оператор, должны сообщать PostgreSQL, как часто и с какой степенью детализации эти статистические данные должны быть собраны. Наблюдаемая вами несоответствие является признаком того, что данные о пластиках устарели или что вы могли бы выиграть от настройки других параметров планировщика.

0 голосов
/ 03 марта 2012

Попробуйте запустить их через объяснение и анализ и опубликовать вывод этого в http://explain.depesz.com/

...