С чего начать диагностику PostgreSQL проблем с производительностью?

Question

У меня есть таблица под названием modifications с 42 столбцами и 84 млн строк. Общий размер составляет 64 ГБ.

Я использую Postgres 9.6.11 на Amazon RDS с 16 ГБ ОЗУ на экземпляре db.m4.xlarge.

Когда я запускаю простой SELECT count(*) FROM modifications; для завершения sh выполнения требуется 380 секунд.

Когда я запускаю SELECT * FROM modifications WHERE post_date = '2016-05-03';, чтобы ограничиться одной датой, требуется 156 секунд, чтобы вернуть в результат 4,6 млн строк.

Когда я ограничиваю набор результатов еще примерно до 1 млн строк, запрос все равно занимает более 100 секунд.

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

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

Я также пробовал добавить больше индексов ... у меня есть индексы по каждому из наиболее часто запрашиваемых столбцов.

Я использую настройки по умолчанию для конфигурации AWS RDS PostgreSQL и пробовал настраивать настройки work_mem, используя SET LOCAL work_mem = 'XXXMB'. Это не имело значения. Другие настройки по умолчанию для таких вещей, как shared_buffers (0,5 ГБ) и effective_cache_size (0,5 ГБ), установлены разумно.

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

EDIT: вот план выполнения для последнего SELECT запроса

Bitmap Heap Scan on modifications  (cost=479407.01..1692971.07 rows=460492 width=279)
  Recheck Cond: ((post_date = '2016-05-03 00:00:00'::timestamp without time zone) AND (change_type = 'residence_address_line_1'::text))
  ->  BitmapAnd  (cost=479407.01..479407.01 rows=460492 width=0)
        ->  Bitmap Index Scan on modifications_post_date_idx  (cost=0.00..130733.87 rows=4478040 width=0)
              Index Cond: (post_date = '2016-05-03 00:00:00'::timestamp without time zone)
        ->  Bitmap Index Scan on modifications_change_type_idx  (cost=0.00..348442.64 rows=8677610 width=0)
              Index Cond: (change_type = 'residence_address_line_1'::text)

Answer 1

Вы должны включить track_io_timing, затем вы должны сделать EXPLAIN (ANALYZE, BUFFERS), чтобы посмотреть на производительность запроса.

Для запроса, план которого вы показали, вероятно, было бы оптимальным иметь многостолбцовый индекс (change_type, post_date). Но невозможно иметь сотни индексов с несколькими столбцами для поддержки сотен различных запросов. Таким образом, вы должны посмотреть на EXPLAIN (ANALYZE, BUFFERS) для этого запроса как с многоколоночным индексом, так и с двумя одиночными индексами.

Вы перечислили 3 совершенно разных запроса. Какой из них вам больше всего нравится? Обычно вам необходимо оптимизировать запрос, чтобы получить нужные вам результаты, вы не можете выбирать среди очень разных запросов в зависимости от того, насколько легко их оптимизировать.