Re: Extending outfuncs support to utility statements

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