| 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-06-29 19:26:20 |
| Message-ID: | 39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> On 20-06-2021, at 17:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-06-29 19:43:28 | Re: Planning performance problem (67626.278ms) |
| Previous Message | Tom Lane | 2021-06-25 18:04:21 | Re: slow performance with cursor |