На что вы обращаете внимание при использовании EXPLAIN ANALYZE, чтобы определить, есть ли улучшения, которые вы можете внести или нет

#postgresql

Вопрос:

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

 
 Limit  (cost=26.16..26.18 rows=10 width=322) (actual time=0.077..0.079 rows=10 loops=1)
   ->  Sort  (cost=26.16..26.19 rows=12 width=322) (actual time=0.076..0.077 rows=10 loops=1)
         Sort Key: like_count DESC, inserted_at DESC
         Sort Method: top-N heapsort  Memory: 28kB
         ->  Bitmap Heap Scan on comments c0  (cost=4.40..25.94 rows=12 width=322) (actual time=0.036..0.049 rows=38 loops=1)
               Recheck Cond: ((post_id = 'dc1ab68f-db3f-4b45-aa48-b5c30298e261'::uuid) AND (parent_id IS NULL))
               Heap Blocks: exact=9
               ->  Bitmap Index Scan on comments_post_id_parent_id_index  (cost=0.00..4.40 rows=12 width=0) (actual time=0.013..0.013 rows=38 loops=1)
                     Index Cond: ((post_id = 'dc1ab68f-db3f-4b45-aa48-b5c30298e261'::uuid) AND (parent_id IS NULL))
 Planning Time: 0.099 ms
 Execution Time: 0.099 ms
(11 rows)

Есть ли какие-либо ключевые моменты, на которые вы обращаете внимание, чтобы сказать: «Этот запрос довольно оптимизирован» или «Вау, есть индекс, который я могу добавить, чтобы сократить всю эту работу»?

Ответ №1:

Первое, что я бы заметил, это то, что для запуска потребовалось менее 1/10 000 секунды, и поэтому вряд ли потребуется ручная оптимизация. И тогда я задаюсь вопросом, почему я вообще начал смотреть на такой быстрый запрос? Конечно, я должен изучать медленные запросы, а не быстрые.

1. Это было после запуска команды 5-6 раз, так что это было в полностью кэшированном состоянии. Вы обычно предпочитаете оценки при первом запуске или после того, как у него было время для кэширования?

2. @PeterR На это сложно ответить в целом. В производственной системе я обычно включал track_io_timing и использовал auto_explain с включенными log_analyze и log_buffers (но с отключенным log_timing, если бы я был в системе с медленным доступом пользователя к системным часам), чтобы увидеть, что происходит в реальных условиях. При тестировании или разработке я бы, вероятно, запускал его повторно, но каждый раз с другим значением для post_id . Таким образом, буферы, используемые совместно, будут кэшироваться, но те, которые относятся к данному post_id, не будут кэшироваться, что кажется наиболее реалистичным.

Ответ №2:

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

1. Bitmap Heap Scan Отличается от сканирования таблицы?

2. ДА. Последовательное сканирование перебирает фактические строки в поисках тех, которые удовлетворяют запросу. В некоторых случаях проверка seq подходит, особенно для небольших таблиц или для запросов, которые в любом случае возвращают большое количество строк.

3. Итак, если у меня включен индекс (post_id, parent_id) , зачем ему выполнять сканирование кучи растровых изображений вместо сканирования индекса?