Re: Planner is getting wrong row count

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: AI Rumman <rummandba(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Planner is getting wrong row count
Date: 2013-04-03 15:34:33
Message-ID: 1365003273.32054.YahooMailNeo@web162905.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

AI Rumman <rummandba(at)gmail(dot)com> 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2013-04-04 08:52:04 Re: Postgres upgrade, security release, where?
Previous Message Vasilis Ventirozos 2013-04-03 08:50:06 Re: Join between 2 tables always executes a sequential scan on the larger table