Re: add_path optimization
От | Tom Lane |
---|---|
Тема | Re: add_path optimization |
Дата | |
Msg-id | 4925.1233772727@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: add_path optimization (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: add_path optimization
|
Список | pgsql-hackers |
I wrote: > Now, since I'm running without any stats, it might be that it's > estimating similar costs for the one-key and two-key merges; but I don't > see why that would happen for you. Off to do some debugging. ... well, actually, it's because I blew off applying any cost correction for this case in cost_mergejoin: * For SEMI and ANTI joins, only one inner tuple need be rescanned for * each group of same-keyed outer tuples (assumingthat all joinquals * are merge quals). This makes the effect small enough to ignore, * so we just set rescannedtuples= 0. Obviously that's not going to be good enough for production --- the parenthetical assumption here is just wrong in the case at hand. That doesn't seem to be the only issue in your example, but it's definitely one of 'em. regards, tom lane
В списке pgsql-hackers по дате отправления: