From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: David Rowley <dgrowleyml@gmail.com>,
        Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
        Andy Fan <zhihui.fan1213@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans
In-reply-to: <20210223020105.kz3rlairv3gjojys@alap3.anarazel.de>
References: 
 <CAApHDvpGX7RN+sh7Hn9HWZQKp53SjKaL=GtDzYheHWiEd-8moQ@mail.gmail.com>
 <CAKU4AWq_K950aYpzLMH5DtYX=5a03dmYgEkeEq0jTcvBQbWnNQ@mail.gmail.com>
 <CAApHDvq9voUu5ShxOvdeFBR8LyWZBy0+SPHSt0N5qLOVaZ2tYw@mail.gmail.com>
 <CAApHDvpXN0nT75ki9jbrAcPckYxzZP_KWdCmZDQs2fb=rNu_5Q@mail.gmail.com>
 <CAApHDvq5FU7miePUoFKUzjzxFHv47Eenz6q8-ay3qiZ3CkwVQQ@mail.gmail.com>
 <4bbece40-d648-b6f9-a323-fcb8f4b45e78@postgrespro.ru>
 <CAApHDvodjxCbOrinbk6rh9M07gMVySQdJBRTxR4PKbxvPuzj3Q@mail.gmail.com>
 <CAApHDvpbusiKMV=vZypdpHHu81u0zMVAp6hu1vg-=gQLBBKUPA@mail.gmail.com>
 <20210223013911.xf2lhaz6pljuxsjj@alap3.anarazel.de>
 <3753634.1614045077@sss.pgh.pa.us>
 <20210223020105.kz3rlairv3gjojys@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 22 Feb 2021 18:01:05 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3795225.1614059027.1@sss.pgh.pa.us>
Date: Tue, 23 Feb 2021 00:43:47 -0500
Message-ID: <3795226.1614059027@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> We could add a wrapper node around "planner expressions" that stores
> metadata about them during planning, without those properties leaking
> over expressions used at other times. E.g. having
> preprocess_expression() return a PlannerExpr that that points to the
> expression as preprocess_expression returns it today. That'd make it
> easy to cache information like volatility. But it also seems
> prohibitively invasive :(.

I doubt it's that bad.  We could cache such info in RestrictInfo
for quals, or PathTarget for tlists, without much new notational
overhead.  That doesn't cover everything the planner deals with
of course, but it would cover enough that you'd be chasing pretty
small returns to worry about more.

			regards, tom lane