Re: Looks like merge join planning time is too big, 55 seconds

Поиск
Список
Период
Сортировка
Искать
От
Sergey Burladyan
Тема
Re: Looks like merge join planning time is too big, 55 seconds
Дата
Msg-id
878v0kuks9.fsf@seb.koffice.internal
Ответ на
Список
Дерево обсуждения
Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Thomas Reiss <thomas.reiss@dalibo.com>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds David Kerr <dmk@mr-paradox.net>
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 Sergey Burladyan <eshkinkot@gmail.com>
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 Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera <alvherre@2ndquadrant.com>
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 Tom Lane <tgl@sss.pgh.pa.us>
Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Looks like merge join planning time is too big, 55 seconds Tom Lane <tgl@sss.pgh.pa.us>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan <eshkinkot@gmail.com>
Tom Lane  writes:

> Jeff Janes  writes:
> > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan  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.

Hmm, I speak about 9.2.2 but in current HEAD this call still exist,
please see: http://doxygen.postgresql.org/selfuncs_8c_source.html#l02976

> 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.

I found debug symbols and send stack trace to mail list, but it blocked
by size, try again with zip

В списке pgsql-performance по дате отправления
От: Tom Lane
Дата:
От: Scott Marlowe
Дата:
FAQ