Postgresql сравнить 2 запроса для оптимизации

Question

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

"Sort  (cost=240.15..242.42 rows=906 width=58) (actual time=72.470..80.575 rows=3066 loops=1)"
"  Sort Key: public.historicoestatusrequisicion.requisicion_id, public.historicoestatusrequisicion.estatusrequisicion_id"
"  Sort Method:  quicksort  Memory: 436kB"
"  ->  Hash Join  (cost=96.44..195.65 rows=906 width=58) (actual time=16.198..46.765 rows=3066 loops=1)"
"        Hash Cond: (public.historicoestatusrequisicion.requisicion_id = public.historicoestatusrequisicion.requisicion_id)"
"        ->  Seq Scan on historicoestatusrequisicion  (cost=0.00..78.66 rows=3066 width=58) (actual time=0.018..8.616 rows=3066 loops=1)"
"        ->  Hash  (cost=95.45..95.45 rows=79 width=7) (actual time=16.132..16.132 rows=904 loops=1)"
"              ->  HashAggregate  (cost=94.66..95.45 rows=79 width=7) (actual time=10.475..13.109 rows=904 loops=1)"
"                    ->  Seq Scan on historicoestatusrequisicion  (cost=0.00..93.99 rows=267 width=7) (actual time=1.309..5.329 rows=904 loops=1)"
"                          Filter: ((usuario_id = 27) AND (estatusrequisicion_id = 1))"
"Total runtime: 88.682 ms"

Второй запрос

  EXPLAIN ANALYZE
  SELECT hist1.historicoestatusrequisicion_id, hist1.requisicion_id, hist1.estatusrequisicion_id, hist1.comentario, hist1.fecha_estatus, hist1.usuario_id
  FROM historicoestatusrequisicion hist1
  JOIN historicoestatusrequisicion hist2 ON hist2.requisicion_id = hist1.requisicion_id
  WHERE hist2.usuario_id = 27 AND hist2.estatusrequisicion_id = 1
  ORDER BY hist1.requisicion_id, hist1.estatusrequisicion_id;

Это результат

"Sort  (cost=248.71..250.97 rows=906 width=58) (actual time=34.833..40.601 rows=3066 loops=1)"
"  Sort Key: hist1.requisicion_id, hist1.estatusrequisicion_id"
"  Sort Method:  quicksort  Memory: 436kB"
"  ->  Hash Join  (cost=97.33..204.21 rows=906 width=58) (actual time=4.320..23.515 rows=3066 loops=1)"
"        Hash Cond: (hist1.requisicion_id = hist2.requisicion_id)"
"        ->  Seq Scan on historicoestatusrequisicion hist1  (cost=0.00..78.66 rows=3066 width=58) (actual time=0.010..5.886 rows=3066 loops=1)"
"        ->  Hash  (cost=93.99..93.99 rows=267 width=7) (actual time=4.289..4.289 rows=904 loops=1)"
"              ->  Seq Scan on historicoestatusrequisicion hist2  (cost=0.00..93.99 rows=267 width=7) (actual time=0.425..2.316 rows=904 loops=1)"
"                    Filter: ((usuario_id = 27) AND (estatusrequisicion_id = 1))"
"Total runtime: 46.387 ms"

Answer 1

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

Он отсортировал все строки на основе идентификатора estatusrequisicion, для этого он использовал быструю сортировку. Время, которое потребовалось, составило 34 мс.

Затем он присоединился к этому результирующему нахождению на hist1.requisicion_id = hist2.requisicion_id. Поскольку это ключевые ключи, он смог выполнить поиск хеша.
Хэш - это способ хранения первичных / внешних ключей. Поле вычисляется в хеш
и скорость поиска равна 1.

Затем он присоединился к этому набору результатов в Historestestatusrequisicion, используя другой первичный / внешний ключ.

Затраты измеряются в произвольных единицах, определяемых параметрами затрат планировщика , фактическое время - это сколько времени (фактического потребовалось) заняло

достойное объяснение планов выполнения начального уровня

Answer 2

Я предлагаю вам посмотреть EnterpriseDB веб-трансляции на Performance Tuning .

Регистрация бесплатная, файлы огромные, но оно того стоит.