From: Evgeny Shishkin <itparanoia@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: AI Rumman <rummandba@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Why does the number of rows are different in actual and estimated.
Date: Fri, 14 Dec 2012 02:40:35 +0400
Message-ID: <55F1445F-304C-41C7-AB55-5ABC19184F00@gmail.com> (raw)
In-Reply-To: <50CA586A.30008@dunslane.net>
References: <CAGoODpdaGPEOyAPkWvLD=0xfQ=k-a8B_fT=Tb6QJ0uNrDv=Hvg@mail.gmail.com>
<50CA586A.30008@dunslane.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On Dec 14, 2012, at 2:36 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 12/13/2012 05:12 PM, AI Rumman wrote:
>> Why does the number of rows are different in actual and estimated?
>>
>
>
> Isn't that in the nature of estimates? An estimate is a heuristic guess at the number of rows it will find for the given query or part of a query. It's not uncommon for estimates to be out by several orders of magnitude. Guaranteeing estimates within bounded accuracy and in a given short amount of time (you don't want your planning time to overwhelm your execution time) isn't possible.
>
The main question i think is what to do with it.
The problem starts here
-> Hash Join (cost=9337.97..18115.71 rows=34489 width=244) (actual time=418.054..1156.453 rows=205420 loops=1)
Hash Cond: (customerdetails.customerid = entity.id)
-> Seq Scan on customerdetails (cost=0.00..4752.46 rows=327146 width=13) (actual time=0.021..176.389 rows=327328 loops=1)
-> Hash (cost=6495.65..6495.65 rows=227386 width=231) (actual time=417.839..417.839 rows=205420 loops=1)
Buckets: 32768 Batches: 1 Memory Usage: 16056kB
-> Index Scan using entity_setype_idx on entity (cost=0.00..6495.65 rows=227386 width=231) (actual time=0.033..2
53.880 rows=205420 loops=1)
Index Cond: ((setype)::text = 'con_s'::text)
-> Index Scan using con_address_pkey on con_address (cost=0.00..0.27 rows=1 width=46) (actual time=0.003..0.004 rows=1 loops=2054
20)
As you see access methods estimates are ok, it is join result set which is wrong.
How to deal with it?
May be a hack with CTE can help, but is there a way to improve statistics correlation?
> cheers
>
> andrew
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: itparanoia@gmail.com, andrew@dunslane.net, rummandba@gmail.com
Subject: Re: Why does the number of rows are different in actual and estimated.
In-Reply-To: <55F1445F-304C-41C7-AB55-5ABC19184F00@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox