совокупная производительность postgres - PullRequest
Новая
       11

совокупная производительность postgres

4 голосов
/ 15 февраля 2012

Я заметил некоторые проблемы с простой агрегированной производительностью в Postgres (8.3).Проблема в том, что если у меня есть таблица (скажем, 200M строк), которая уникальна по (customer_id, order_id), то запрос select customer_id,max(order_id) from larger_table group by customer_id более чем на порядок медленнее, чем простая программа Java / JDBC, которая выполняет следующие действия:

1) Инициализировать пустую клиентскую карту HashMap (это будет ID карты -> максимальный размер заказа) 2) выполнить «select customer_id, order_id from large_table» и получить набор результатов потоковой передачи 3) выполнить итерации по набору результатов,в каждом ряду выполняется что-то вроде следующего: 

long id = resultSet.getLong("customer_id");
long order = resultSet.getLong("order_id");
if (!customerMap.containsKey(id)) 
    customerMap.put(id,order);
else 
    customerMap.put(id,Math.max(order,customerMap.get(id)));

Ожидается ли эта разница в производительности?Я не должен думать, так как я представляю, что вышесказанное довольно близко к тому, что происходит внутри.Это доказательство того, что с базой данных что-то не так / неправильно настроено?

1 Ответ

6 голосов
/ 15 февраля 2012

Возможно, ваша настройка work_mem слишком низкая. Я бы проверил это первым. Я был укушен этим недавно. Вторая наиболее вероятная проблема - это отсутствие индекса внешнего ключа.

Экспозиция следует.

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

  1. Вы используете актуальную версию? Каждый выпуск версии между 7.4 и 9.0 приносил с собой существенные улучшения производительности - если обновление возможно, рекомендуется.
  2. Используете ли вы свой эталон на реалистичных данных? Планировщик запросов PostgreSQL будет создавать разные планы для одной и той же таблицы с разными данными или разными объемами данных. Убедитесь, что вы всегда тестируете с реалистичными данными.
  3. Какова ваша конфигурация PostgreSQL? Параметр work_mem низок из коробки, я сам сталкивался с ситуациями, связанными с GROUP BY, когда он искусственно выбирал неправильный план, потому что просто не думал, что у него достаточно рабочей памяти для сортировки результатов.
  4. Ваш код Java работает на той же машине, что и ваша база данных? Если нет, возможно, вы видите различия между компьютерами, а не различия между подходами.
  5. Вам не хватает индекса? PostgreSQL не создает индексы автоматически для внешних ключей, только для первичных ключей. Я также был укушен этим, но если вы гуглите вокруг, вы можете найти скрипт, который обнаружит и добавит отсутствующие индексы внешнего ключа.

Не изучая план запроса, не стоит догадываться, какую стратегию реализации PostgreSQL выбрал для данного запроса.

...