AI Rumman <rummandba@xxxxxxxxx> wrote: > Why is the following query getting wrong estimation of rows? > I am using Postgresql 9.2.1 with default_statistics_target = 100. > I execute vacuum analyze each night. > Hash Join (cost=14067.90..28066.53 rows=90379 width=26) (actual time=536.009..1772.910 rows=337139 loops=1) > Hash Cond: (leads.leadid = entity.id) > -> Seq Scan on leads (cost=0.00..7764.83 rows=533002 width=18) (actual time=0.008..429.576 rows=532960 loops=1) > Filter: (converted = 0) > -> Hash (cost=9406.25..9406.25 rows=372932 width=16) (actual time=535.800..535.800 rows=342369 loops=1) > Buckets: 65536 Batches: 1 Memory Usage: 16049kB > -> Index Scan using entity_type_idx on entity (cost=0.00..9406.25 rows=372932 width=16) (actual time=0.030..305.250 rows=342369 loops=1) > Index Cond: ((type)::text = 'Leads'::text) The estimates match up well with actual until the hash join. That suggests that there is a correlation between the join conditions and the other selection criteria which the planner doesn't know about. Right now PostgreSQL has no way to adjust estimates based on such correlations. If an inefficient plan is being chosen due to this, there are a few tricks to coerce the plan. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
