Re: Extending outfuncs support to utility statements

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Extending outfuncs support to utility statements
Date: 2022-07-10 21:43:48
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


> 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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-07-10 21:46:22 Re: automatically generating node support functions
Previous Message Andres Freund 2022-07-10 21:39:00 Re: pg_waldump got an error with waldump file generated by initdb