Re: Planning performance problem (67626.278ms)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planning performance problem (67626.278ms)
Дата
Msg-id 500142.1624995808@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Planning performance problem (67626.278ms)  (Manuel Weitzman <manuelweitzman@gmail.com>)
Ответы Re: Planning performance problem (67626.278ms)
Список pgsql-performance
Manuel Weitzman <manuelweitzman@gmail.com> writes:
>> 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().

That seems a bit broken; a given WHERE clause should produce only one
RestrictInfo.  Can you provide a more concrete example?

            regards, tom lane



В списке pgsql-performance по дате отправления:

Предыдущее
От: Manuel Weitzman
Дата:
Сообщение: Re: Planning performance problem (67626.278ms)
Следующее
От: Manuel Weitzman
Дата:
Сообщение: Re: Planning performance problem (67626.278ms)