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 обсуждение исходный текст |
| Ответ на | Re: Looks like merge join planning time is too big, 55 seconds (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-performance |
Tom Lane <tgl@sss.pgh.pa.us> writes: > 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. 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 по дате отправления: