| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manuel Weitzman <manuelweitzman(at)gmail(dot)com> |
| 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:43:28 |
| Message-ID: | 500142.1624995808@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Manuel Weitzman <manuelweitzman(at)gmail(dot)com> writes:
>> 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().
That seems a bit broken; a given WHERE clause should produce only one
RestrictInfo. Can you provide a more concrete example?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manuel Weitzman | 2021-06-29 21:35:38 | Re: Planning performance problem (67626.278ms) |
| Previous Message | Manuel Weitzman | 2021-06-29 19:26:20 | Re: Planning performance problem (67626.278ms) |