Re: surprisingly expensive join planning query - Mailing list pgsql-hackers

From Tom Lane
Subject Re: surprisingly expensive join planning query
Date
Msg-id 16939.1575224824@sss.pgh.pa.us
Whole thread Raw
In response to surprisingly expensive join planning query  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: surprisingly expensive join planning query  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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 by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Tomas Vondra
Date:
Subject: Re: surprisingly expensive join planning query