[Solved] Consider this EXPLAIN output for a query joining two tables:Hash Join (cost=10.00..30.00 rows=500 width=150) Hash Cond: (a.id = b.... | PostgreSQL

PostgreSQL - Performance Tuning

Consider this EXPLAIN output for a query joining two tables:

Hash Join  (cost=10.00..30.00 rows=500 width=150)
  Hash Cond: (a.id = b.a_id)
  -> Seq Scan on a
  -> Hash  
       -> Seq Scan on b

What does this plan imply about the join strategy?

APostgreSQL builds a hash table from table b and scans table a sequentially

BPostgreSQL uses nested loops to join tables a and b

CPostgreSQL sorts both tables before joining

DPostgreSQL uses an index scan on both tables

Step-by-Step Solution

Solution:

Step 1: Analyze Hash Join components
Hash Join builds a hash table from one input (here table b) for fast lookups.
Step 2: Understand scan types
Both tables are scanned sequentially; no index or sort is used.
Final Answer:
PostgreSQL builds a hash table from table b and scans table a sequentially -> Option A
Quick Check:
Hash Join = hash build + sequential scan [OK]

Quick Trick: Hash Join builds hash on one table, scans the other [OK]

Common Mistakes:

Master "Performance Tuning" in PostgreSQL

9 interactive learning modes - each teaches the same concept differently

Consider this EXPLAIN output for a query joining two tables: