Re: Planning performance problem (67626.278ms)

Поиск
Список
Период
Сортировка
От Manuel Weitzman
Тема Re: Planning performance problem (67626.278ms)
Дата
Msg-id 39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com
обсуждение исходный текст
Ответ на Re: Planning performance problem (67626.278ms)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Planning performance problem (67626.278ms)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: slow performance with cursor
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Planning performance problem (67626.278ms)