Hi,
On 2022-07-10 19:12:52 -0400, Tom Lane wrote:
> 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 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