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

From Manuel Weitzman
Subject Re: Planning performance problem (67626.278ms)
Date
Msg-id B7F75B2A-A241-46BA-B6FF-E95874C39D65@gmail.com
Whole thread Raw
In response to Re: Planning performance problem (67626.278ms)  (Manuel Weitzman <manuelweitzman@gmail.com>)
List 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


Attachment

pgsql-performance by date:

Previous
From: Ayub Khan
Date:
Subject: Re: slow performance with cursor
Next
From: David Rowley
Date:
Subject: Re: Planning performance problem (67626.278ms)