Re: Why does the number of rows are different in actual and estimated.
От | Evgeny Shishkin |
---|---|
Тема | Re: Why does the number of rows are different in actual and estimated. |
Дата | |
Msg-id | F32F9E7A-1271-4864-AD2D-F95DC251D60D@gmail.com обсуждение исходный текст |
Ответ на | Re: Why does the number of rows are different in actual and estimated. (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Why does the number of rows are different in actual and estimated.
|
Список | pgsql-performance |
On Dec 14, 2012, at 3:09 AM, Andrew Dunstan <andrew@dunslane.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.453rows=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 theOP 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance
В списке pgsql-performance по дате отправления: