Re: Planning performance problem (67626.278ms) - Mailing list pgsql-performance

From Tom Lane
Subject Re: Planning performance problem (67626.278ms)
Date
Msg-id 1578974.1624223191@sss.pgh.pa.us
Whole thread Raw
In response to Re: Planning performance problem (67626.278ms)  (Manuel Weitzman <manuelweitzman@gmail.com>)
List pgsql-performance
Manuel Weitzman <manuelweitzman@gmail.com> writes:
> I've written a very naive (and crappy) patch to show how adding
> memorization to get_actual_variable_range() could help the planner on
> scenarios with a big number of joins.

So ... the reason why there's not caching of get_actual_variable_range
results already is that I'd supposed it wouldn't be necessary given
the caching of selectivity estimates that happens at the RestrictInfo
level.  I don't have any objection in principle to adding another
caching layer if that one's not working well enough, but I think it'd
be wise to first understand why it's needed.

            regards, tom lane



pgsql-performance by date:

Previous
From: Manuel Weitzman
Date:
Subject: Re: Planning performance problem (67626.278ms)
Next
From: Ranier Vilela
Date:
Subject: Re: Planning performance problem (67626.278ms)