From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: Extending outfuncs support to utility statements
In-reply-to: <20220710214348.b63jkf3ko5tkeldz@awork3.anarazel.de>
References: <4159834.1657405226@sss.pgh.pa.us>
 <20220710214348.b63jkf3ko5tkeldz@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sun, 10 Jul 2022 14:43:48 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <816651.1657494772.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 10 Jul 2022 19:12:52 -0400
Message-ID: <816652.1657494772@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/816652.1657494772%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-07-09 18:20:26 -0400, Tom Lane wrote:
>> For my taste, the circa 20K growth in outfuncs.o is an okay
>> price for being able to inspect utility statements more easily.
>> However, I'm less thrilled with the 30K growth in readfuncs.o,
>> because I can't see that we'd get any direct benefit from that.
>> So I think a realistic proposal is to enable outfuncs support
>> but keep readfuncs disabled.

> Another approach could be to mark those paths as "cold", so they are pla=
ced
> further away, reducing / removing potential overhead due to higher iTLB =
misses
> etc. 30K of disk space isn't worth worrying about.

They're not so much "cold" as "dead", so I don't see the point
of having them at all.  If we ever start allowing utility commands
(besides NOTIFY) in stored rules, we'd need readfuncs support then
... but at least in the short run I don't see that happening.

			regards, tom lane