Re: surprisingly expensive join planning query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: surprisingly expensive join planning query
Дата
Msg-id 16939.1575224824@sss.pgh.pa.us
обсуждение исходный текст
Ответ на surprisingly expensive join planning query  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: surprisingly expensive join planning query  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> It seems most of this comesfrom find_mergeclauses_for_outer_pathkeys()
> which builds matched_restrictinfos and then just leaves it allocated.
> After pfreeing this (see attached patch), the memory usage gets way down
> and the query completes.

Interesting.  The memory leak was probably much less bad before
commit 1cff1b95a, since in the old List implementation this code
would have leaked only a list header.  It makes sense to me to
add the list_free.

Alternatively, it'd be possible to get rid of the separate List
altogether, and just add the rinfo's to "mergeclauses" immediately.
The functionality of the separate list could be replaced by a
bool variable remembering whether we found any matches in this
pass through the loop.  I think the code would be a little less
clear that way, but this report makes it clear that it's a
performance bottleneck, so maybe we should just change it.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: surprisingly expensive join planning query