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