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: <20210223013911.xf2lhaz6pljuxsjj@alap3.anarazel.de>
References: 
 <CAApHDvraky-j=gq01ABwUw+QvQr+KvDc96gObkBm_k0EhvBquw@mail.gmail.com>
 <CAApHDvqvGZUPKHO+4Xp7Lm_q1OXBo2Yp1=5pVnEUcr4dgOXxEg@mail.gmail.com>
 <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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 22 Feb 2021 17:39:11 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3753633.1614045077.1@sss.pgh.pa.us>
Date: Mon, 22 Feb 2021 20:51:17 -0500
Message-ID: <3753634.1614045077@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Except for the annoying issue that that we pervasively use Lists as
> expressions, I'd argue that we should actually cache "subtree
> volatility" in Expr nodes, similar to the way we use OpExpr.opfuncid
> etc. That'd allow us to make contain_volatile_functions() very cheap

... and completely break changing volatility with ALTER FUNCTION.
The case of OpExpr.opfuncid is okay only because we don't provide
a way to switch an operator's underlying function.  (See also
9f1255ac8.)

It'd certainly be desirable to reduce the number of duplicated
function property lookups in the planner, but I'm not convinced
that that is a good way to go about it.

			regards, tom lane