Re: Wrong plan or what ?
От | Mendola Gaetano |
---|---|
Тема | Re: Wrong plan or what ? |
Дата | |
Msg-id | 010601c35080$10256cf0$152aa8c0@GMENDOLA2 обсуждение исходный текст |
Ответ на | Wrong plan or what ? ("Mendola Gaetano" <mendola@bigfoot.com>) |
Список | pgsql-performance |
"Josh Berkus" <josh@agliodbs.com> > Gaetano, > > > QUERY PLAN > > Hash Join (cost=265.64..32000.76 rows=40612 width=263) (actual > > time=11074.21..11134.28 rows=10 loops=1) > > Hash Cond: ("outer".id_user = "inner".id_user) > > -> Seq Scan on user_logs ul (cost=0.00..24932.65 rows=1258965 width=48) > > (actual time=0.02..8530.21 rows=1258966 loops=1) > > OK, here's your problem > > The planner thinks that you're going to get 40162 rows out of the final join, > not 10. If the row estimate was correct, then the Seq Scan would be a > reasonable plan. But it's not. Here's some steps you can take to clear > things up for the planner: > > 1) Make sure you've VACUUM ANALYZED > 2) Adjust the following postgresql.conf statistics: > a) effective_cache_size: increase to 70% of available (not used by other > processes) RAM. > b) random_page_cost: decrease, maybe to 2. > c) default_statistics_target: try increasing to 100 > (warning: this will significantly increase the time required to do ANALYZE) > > Then test again! No improvement at all, I pushed default_statistics_target to 1000 but the rows expected are still 40612 :-( Of course I restarted the postmaster and I vacuumed analyze the DB Thank you Gaetano
В списке pgsql-performance по дате отправления: