Re: Planning performance problem (67626.278ms)

Поиск
Список
Период
Сортировка
От Manuel Weitzman
Тема Re: Planning performance problem (67626.278ms)
Дата
Msg-id B7F75B2A-A241-46BA-B6FF-E95874C39D65@gmail.com
обсуждение исходный текст
Ответ на Re: Planning performance problem (67626.278ms)  (Manuel Weitzman <manuelweitzman@gmail.com>)
Список pgsql-performance
> On 30-06-2021, at 16:56, Manuel Weitzman <manuelweitzman@gmail.com> wrote:
> 
> One way in which I see possible to share this kind of information (of
> extremal values) across RestrictInfos is to store the known variable
> ranges in PlannerInfo (or within a member of such struct), which seems
> to be around everywhere it would be needed.

I have written a new patch that's (hopefully) better than the first
one I sent, to store the extremal index values within PlannerInfo.

> it is also possible to reproduce the increasing cost in planning
> buffers for each new join on a distinct table being added:
> 
> [...]
> 

> I can imagine that deconstruct_jointree() and
> generate_join_implied_equalities() would generate multiple
> RestrictInfos, in which many of them a constraint on a.a would be
> involved (each involving a different table).

I also attached an example in which there are RestrictInfos generated
for multiple tables instead of just a single aliased one. The buffers
read for planning also increase with each join added to the query.


Best regards,
Manuel


Вложения

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

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