Re: Experimenting with hash tables inside pg_dump

Hi,

On 2021-10-21 16:37:57 -0700, Andres Freund wrote:
> On 2021-10-21 18:27:25 -0400, Tom Lane wrote:
> > (a) the executable size increases by a few KB --- apparently, even
> > the minimum subset of simplehash.h's functionality is code-wasteful.
> 
> Hm. Surprised a bit by that. In an optimized build the difference is a
> smaller, at least.
> 
> optimized:
>    text	   data	    bss	    dec	    hex	filename
>  448066	   7048	   1368	 456482	  6f722	src/bin/pg_dump/pg_dump
>  447530	   7048	   1496	 456074	  6f58a	src/bin/pg_dump/pg_dump.orig
> 
> debug:
>    text	   data	    bss	    dec	    hex	filename
>  516883	   7024	   1352	 525259	  803cb	src/bin/pg_dump/pg_dump
>  509819	   7024	   1480	 518323	  7e8b3	src/bin/pg_dump/pg_dump.orig
> 
> The fact that optimization plays such a role makes me wonder if a good chunk
> of the difference is the slightly more complicated find{Type,Func,...}ByOid()
> functions.

It's not that.

In a debug build a good chunk of it is due to a bunch of Assert()s. Another
part is that trivial helper functions like SH_PREV() don't get inlined.

The increase for an optimized build seems to boil down to pg_log_error()
invocations. If I replace those with an exit(1), the resulting binaries are
within 100 byte.

If I prevent the compiler from inlining findObjectByCatalogId() in all the
find*ByOid() routines, your version is smaller than master even without other
changes.

Greetings,

Andres Freund