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