From: Tom Lane <tgl@sss.pgh.pa.us>
To: Manuel Weitzman <manuelweitzman@gmail.com>
cc: Ranier Vilela <ranier.vf@gmail.com>, David Rowley <dgrowleyml@gmail.com>,
        Jeremy Schneider <schnjere@amazon.com>,
        "pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>,
        Andres Freund <andres@anarazel.de>
Subject: Re: Planning performance problem (67626.278ms)
In-reply-to: <39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com>
References: <6d58f68e-ed1a-c48e-1440-691554f6e1e7@9livesdata.com>
 <CAFj8pRDDnOVNcU7dx4+oKH0x4-DsmL3XRWppQ8Cf5wwJ=G2fPg@mail.gmail.com>
 <20190408144210.GG10080@telsasoft.com>
 <b145b428-3351-ec86-d522-100a5bf8ded7@amazon.com>
 <20190408232644.r6xixkeulsmomwfj@alap3.anarazel.de>
 <3f5e5673-06aa-bf7c-cdb7-0e053c45ba26@amazon.com>
 <CAApHDvq9o1J45is6w-3Gv1UgtuDQ4eQP4UhFPQSnQmEH_EijvQ@mail.gmail.com>
 <767433.1619015825@sss.pgh.pa.us>
 <EFE95962-F088-45E2-BD13-AA5012829A69@gmail.com>
 <F06D0C00-DE75-4688-98B0-85A46E8F312C@gmail.com>
 <CAEudQApVF7TX-EJXwBz4TUhH6NzNB-wXqhs4wj+qSe6Vw3H5-Q@mail.gmail.com>
 <1588548.1624234651@sss.pgh.pa.us>
 <39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com>
Comments: In-reply-to Manuel Weitzman <manuelweitzman@gmail.com>
	message dated "Tue, 29 Jun 2021 15:26:20 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <500141.1624995808.1@sss.pgh.pa.us>
Date: Tue, 29 Jun 2021 15:43:28 -0400
Message-ID: <500142.1624995808@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/500142.1624995808%40sss.pgh.pa.us>
Precedence: bulk

Manuel Weitzman <manuelweitzman@gmail.com> writes:
>> On 20-06-2021, at 17:06, Tom Lane <tgl@sss.pgh.pa.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