Hash Join vs Hash Semi Join

PostgreSQL 9.2

Estou tentando entender a diferença entre Hash Semi Joine apenas Hash Join.

Aqui estão duas consultas:

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

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

Como pode ser visto, a única diferença nos planos é que, no primeiro caso, o precipitado consome 7kB, mas no segundo 37kBe que o nó é Hash Semi Join.

Mas não entendo a diferença no tamanho da hashtable. O Hashnó usa perfeitamente o mesmo Seq Scannó que possui o mesmo Filter. Por que existe a diferença?

postgresql join hashing

— St.Antario
fonte

Você já viu a saída real das consultas? Ou use explain (analyze, verbose).

— jjanes

Na primeira consulta, apenas o customer_id precisa ser salvo da customerstabela de hash, porque esses são os únicos dados necessários para implementar a semi-junção.

Na segunda consulta, todas as colunas precisam ser armazenadas na tabela de hash, porque você está selecionando todas as colunas da tabela (usando *) em vez de apenas testar a existência do customer_id.

— jjanes
fonte