Re: Slow inner join, but left join is fast
От | Jeremy Haile |
---|---|
Тема | Re: Slow inner join, but left join is fast |
Дата | |
Msg-id | 1168454304.25047.1168597535@webmail.messagingengine.com обсуждение исходный текст |
Ответ на | Re: Slow inner join, but left join is fast (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Slow inner join, but left join is fast
|
Список | pgsql-performance |
I'm pretty sure it didn't analyze in between - autovac is turned off and I ran the test multiple times before posting. But since I can't reproduce it anymore, I can't be 100% sure. And it certainly doesn't make sense that the estimate for the index scan would change based on an unrelated join condition. If I ever get it to happen again, I'll be more careful and repost if it is a real issue. Thanks for pointing me in the right direction! On Wed, 10 Jan 2007 13:38:15 -0500, "Tom Lane" <tgl@sss.pgh.pa.us> said: > "Jeremy Haile" <jhaile@fastmail.fm> writes: > > I still don't understand why the inner join would be so different from > > the left join prior to the analyze. > > Are you sure you hadn't analyzed in between? Or maybe autovac did it > for you? The reason for the plan change is the change from estimating > 1 row matching the transaction_date range constraint, to estimating lots > of them, and the join type away up at the top would surely not have > affected that. > > regards, tom lane
В списке pgsql-performance по дате отправления: