Re: Experimenting with hash tables inside pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Experimenting with hash tables inside pg_dump
Date: 2021-10-22 19:41:07
Message-ID: 2819956.1634931667@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> Which made me look at the code invoking it from simplehash. I think the patch that made simplehash work in frontend code isn'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 remove register 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-22 19:43:00 Re: [PATCH] Make ENOSPC not fatal in semaphore creation
Previous Message Tom Lane 2021-10-22 19:26:49 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES