From: Tom Lane <tgl@sss.pgh.pa.us>
To: Manuel Weitzman <manuelweitzman@gmail.com>
cc: 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: <F06D0C00-DE75-4688-98B0-85A46E8F312C@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>
Comments: In-reply-to Manuel Weitzman <manuelweitzman@gmail.com>
	message dated "Sat, 19 Jun 2021 20:09:58 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1578973.1624223191.1@sss.pgh.pa.us>
Date: Sun, 20 Jun 2021 17:06:31 -0400
Message-ID: <1578974.1624223191@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1578974.1624223191%40sss.pgh.pa.us>
Precedence: bulk

Manuel Weitzman <manuelweitzman@gmail.com> writes:
> I've written a very naive (and crappy) patch to show how adding
> memorization to get_actual_variable_range() could help the planner on
> scenarios with a big number of joins.

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.

			regards, tom lane