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

From Manuel Weitzman
Subject Re: Planning performance problem (67626.278ms)
Date
Msg-id 39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com
Whole thread Raw
In response to Re: Planning performance problem (67626.278ms)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Planning performance problem (67626.278ms)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
> On 20-06-2021, at 17:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> 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.

For what I could make out from the code, the caching done at the
RestrictInfo level is already saving a lot of work, but there's a
different RestrictInfo instance for each alternative path created by
make_one_rel().
I wouldn't know how to reuse instances of RestrictInfo or if that
would even be the correct approach. My guess is that doing so would
be incorrect.

I'll improve the patch with the suggestions from Ranier and you in
the meantime.


Best regards,
Manuel



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: slow performance with cursor
Next
From: Tom Lane
Date:
Subject: Re: Planning performance problem (67626.278ms)