From: | Manuel Weitzman <manuelweitzman(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Planning performance problem (67626.278ms) |
Date: | 2021-07-01 20:49:44 |
Message-ID: | B7F75B2A-A241-46BA-B6FF-E95874C39D65@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> On 30-06-2021, at 16:56, Manuel Weitzman <manuelweitzman(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
actual_variable_range_cache.patch | application/octet-stream | 5.6 KB |
planning_buffers.sql | application/octet-stream | 1.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-07-02 09:55:36 | Re: Planning performance problem (67626.278ms) |
Previous Message | Ayub Khan | 2021-07-01 20:25:13 | Re: slow performance with cursor |