Re: Extending outfuncs support to utility statements

Hi,

On 2022-07-10 19:12:52 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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 placed
> > 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.

It would allow us to test utility outfuncs as part of the
WRITE_READ_PARSE_PLAN_TREES check. Not that that's worth very much.

I guess it could be a minor help in making a few more utility commands benefit
from paralellism?

Anyway, as mentioned earlier, I'm perfectly fine not supporting readfuns for
utility statements for now.

Greetings,

Andres Freund