Re: merge join killing performance
От | Tom Lane |
---|---|
Тема | Re: merge join killing performance |
Дата | |
Msg-id | 21497.1274287983@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: merge join killing performance (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: merge join killing performance
Re: merge join killing performance |
Список | pgsql-performance |
Matthew Wakeling <matthew@flymine.org> writes: > On Tue, 18 May 2010, Scott Marlowe wrote: >> Aggregate (cost=902.41..902.42 rows=1 width=4) >> -> Merge Join (cost=869.97..902.40 rows=1 width=4) >> Merge Cond: (f.eid = ev.eid) >> -> Index Scan using files_eid_idx on files f >> (cost=0.00..157830.39 rows=3769434 width=8) > Okay, that's weird. How is the cost of the merge join only 902, when the > cost of one of the branches 157830, when there is no LIMIT? It's apparently estimating (wrongly) that the merge join won't have to scan very much of "files" before it can stop because it finds an eid value larger than any eid in the other table. So the issue here is an inexact stats value for the max eid. regards, tom lane
В списке pgsql-performance по дате отправления: