Hash Join против Hash Semi Join


8

PostgreSQL 9.2

Я пытаюсь понять разницу между Hash Semi Joinи просто Hash Join.

Вот два запроса:

я

EXPLAIN ANALYZE SELECT * FROM orders WHERE customerid IN (SELECT
customerid FROM customers WHERE state='MD');

Hash Semi Join  (cost=740.34..994.61 rows=249 width=30) (actual time=2.684..4.520 rows=120 loops=1)
  Hash Cond: (orders.customerid = customers.customerid)
  ->  Seq Scan on orders  (cost=0.00..220.00 rows=12000 width=30) (actual time=0.004..0.743 rows=12000 loops=1)
  ->  Hash  (cost=738.00..738.00 rows=187 width=4) (actual time=2.664..2.664 rows=187 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 7kB
        ->  Seq Scan on customers  (cost=0.00..738.00 rows=187 width=4) (actual time=0.018..2.638 rows=187 loops=1)
              Filter: ((state)::text = 'MD'::text)
              Rows Removed by Filter: 19813

II

EXPLAIN ANALYZE SELECT * FROM orders o JOIN customers c ON o.customerid = c.customerid WHERE c.state = 'MD'

Hash Join  (cost=740.34..1006.46 rows=112 width=298) (actual time=2.831..4.762 rows=120 loops=1)
  Hash Cond: (o.customerid = c.customerid)
  ->  Seq Scan on orders o  (cost=0.00..220.00 rows=12000 width=30) (actual time=0.004..0.768 rows=12000 loops=1)
  ->  Hash  (cost=738.00..738.00 rows=187 width=268) (actual time=2.807..2.807 rows=187 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 37kB
        ->  Seq Scan on customers c  (cost=0.00..738.00 rows=187 width=268) (actual time=0.018..2.777 rows=187 loops=1)
              Filter: ((state)::text = 'MD'::text)
              Rows Removed by Filter: 19813

Как видно, единственное различие в планах состоит в том, что в первом случае потребляет hastable 7kB, а во втором 37kB- узел Hash Semi Join.

Но я не понимаю разницы в размере хеш-таблицы. HashУзел использует совершенно тот же самый Seq Scanузел , имеющий те же Filter. Почему есть разница?


Вы смотрели на фактический результат запросов? Или используйте explain (analyze, verbose).
Джанес

Ответы:


5

В первом запросе необходимо сохранить только customer_id из customersхеш-таблицы, потому что это единственные данные, необходимые для реализации полусоединения.

Во втором запросе все столбцы должны быть сохранены в хеш-таблице, потому что вы выбираете все столбцы из таблицы (используя *), а не просто проверяете наличие customer_id.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.