| From: | Evgeny Shishkin <itparanoia(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, AI Rumman <rummandba(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Why does the number of rows are different in actual and estimated. |
| Date: | 2012-12-13 23:13:29 |
| Message-ID: | F32F9E7A-1271-4864-AD2D-F95DC251D60D@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Dec 14, 2012, at 3:09 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 12/13/2012 05:42 PM, Claudio Freire wrote:
>> And it looks like it all may be starting to go south 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)
>
>
> Well, it looks like it's choosing a join order that's quite a bit different from the way the query is expressed, so the OP might need to play around with forcing the join order some.
>
>
OP joins 8 tables, and i suppose join collapse limit is set to default 8. I thought postgresql's optimiser is not mysql's.
> cheers
>
> andrew
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-12-13 23:36:54 | Re: Why does the number of rows are different in actual and estimated. |
| Previous Message | Andrew Dunstan | 2012-12-13 23:09:42 | Re: Why does the number of rows are different in actual and estimated. |