Hi, On 2022-07-09 18:20:26 -0400, Tom Lane wrote: > We've long avoided building I/O support for utility-statement node > types, mainly because it didn't seem worth the trouble to write and > maintain such code by hand. Now that the automatic node-support-code > generation patch is in, that argument is gone, and it's just a matter > of whether the benefits are worth the backend code bloat. I can > see two benefits worth considering: > > * Seems like having such support would be pretty useful for > debugging.
Agreed. > So I looked into how much code are we talking about. On my > RHEL8 x86_64 machine, the code sizes for outfuncs/readfuncs > as of HEAD are > > $ size outfuncs.o readfuncs.o > text data bss dec hex filename > 117173 0 0 117173 1c9b5 outfuncs.o > 64540 0 0 64540 fc1c readfuncs.o > > If we just open the floodgates and enable both outfuncs and > readfuncs support for all *Stmt nodes (plus some node types > that thereby become dumpable, like AlterTableCmd), then > this becomes > > $ size outfuncs.o readfuncs.o > text data bss dec hex filename > 139503 0 0 139503 220ef outfuncs.o > 95562 0 0 95562 1754a readfuncs.o > > 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. Don't really have an opinion on this. Greetings, Andres Freund
