Re: Experimenting with hash tables inside pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Experimenting with hash tables inside pg_dump
Date
Msg-id 2819956.1634931667@sss.pgh.pa.us
Whole thread Raw
In response to Re: Experimenting with hash tables inside pg_dump  (Andres Freund <andres@anarazel.de>)
Responses Re: Experimenting with hash tables inside pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Which made me look at the code invoking it from simplehash. I think the patch that made simplehash work in frontend
codeisn't quite right, because pg_log_error() returns... 

Indeed, that's broken.  I guess we want pg_log_fatal then exit(1).

> Wonder if we should mark simplehash's grow as noinline? Even with a single caller it seems better to not inline it to
removeregister allocator pressure. 

Seems plausible --- you want me to go change that?

> The only thought I had wrt the patch is that I'd always create the hash
> table.

That'd require adding an explicit init function and figuring out where to
call it, which we could do but I didn't (and don't) think it's worth the
trouble.  One more branch here isn't going to matter, especially given
that we can't even measure the presumed macro improvement.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mikhail
Date:
Subject: Re: [PATCH] Make ENOSPC not fatal in semaphore creation
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Make ENOSPC not fatal in semaphore creation