Re: Looks like merge join planning time is too big, 55 seconds
От | Tom Lane |
---|---|
Тема | Re: Looks like merge join planning time is too big, 55 seconds |
Дата | |
Msg-id | 1899.1375458648@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Looks like merge join planning time is too big, 55 seconds (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Looks like merge join planning time is too big, 55 seconds
Re: Looks like merge join planning time is too big, 55 seconds |
Список | pgsql-performance |
Jeff Janes <jeff.janes@gmail.com> writes: > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan <eshkinkot@gmail.com> wrote: >> If I not mistaken, may be two code paths like this here: >> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity -> get_actual_variable_range -> index_getnext >> (2) scalargtsel -> scalarineqsel -> ineq_histogram_selectivity -> get_actual_variable_range -> index_getnext > Yeah, I think you are correct. mergejoinscansel does *not* call scalarineqsel, nor get_actual_variable_range. It calls get_variable_range, which only looks at the pg_statistic entries. I think we need to see the actual stack traces, not incomplete versions. It's possible that the situation here involves bloat in pg_statistic, but we're just leaping to conclusions if we assume that that's where the index fetches are occurring. regards, tom lane
В списке pgsql-performance по дате отправления: