Tomas Vondra writes:
>> (Speaking of which, I don't quite see why this would have been a problem
>> once you got past geqo_threshold; the context resets that GEQO does
>> should've kept things under control.)
> Not sure I follow. geqo_threshold is 12 by default, and the OOM issues
> are hapenning
On Mon, Dec 02, 2019 at 03:21:47PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Dec 01, 2019 at 02:17:15PM -0500, Tom Lane wrote:
LGTM.
Thanks. Do you think this is backpatch-worthy? I'm leaning to yes, but
maybe tweaking this just in master is fine. The query is somewhat
artificial
Tomas Vondra writes:
> On Sun, Dec 01, 2019 at 02:17:15PM -0500, Tom Lane wrote:
>> LGTM.
> Thanks. Do you think this is backpatch-worthy? I'm leaning to yes, but
> maybe tweaking this just in master is fine. The query is somewhat
> artificial and there are probably ways to rewrite it.
I don't o
On Sun, Dec 01, 2019 at 02:17:15PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Dec 01, 2019 at 01:27:04PM -0500, Tom Lane wrote:
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
Tomas Vondra writes:
> On Sun, Dec 01, 2019 at 01:27:04PM -0500, Tom Lane wrote:
>> 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 variab
On Sun, Dec 01, 2019 at 01:27:04PM -0500, Tom Lane wrote:
Tomas Vondra 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
an
Tomas Vondra 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
Hi,
while evaluating one of the CF patches (the incremental sort one, but
that's mostly irrelevant), I ran into a strange issue with join planning
for a fairly simple query. I needed to asses how the patch affects query
planning for different GUCs, so I ran a group of queries and stashed the
resu
