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 17:32:30 |
Message-ID: | 2721905.1634923950@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:
>> 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.
> If I prevent the compiler from inlining findObjectByCatalogId() in all the
> find*ByOid() routines, your version is smaller than master even without other
> changes.
Hmm ... seems to depend a lot on which compiler you use.
I was originally looking at it with gcc 8.4.1 (RHEL8 default),
x86_64. On that, adding pg_noinline to findObjectByCatalogId
helps a little, but it's still 3.6K bigger than HEAD.
I then tried gcc 11.2.1/x86_64, finding that the patch adds
about 2K and pg_noinline makes no difference.
I also tried it on Apple's clang 13.0.0, both x86_64 and ARM
versions. On that, the change seems to be a wash or slightly
smaller, with maybe a little benefit from pg_noinline but not
much. It's hard to tell for sure because size(1) seems to be
rounding off to a page boundary on that platform.
Anyway, these are all sub-one-percent changes in the code
size, so probably we should not sweat that much about it.
I'm kind of leaning now towards pushing the patch, just
on the grounds that getting rid of all those single-purpose
index arrays (and likely future need for more of them)
is worth it from a maintenance perspective.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2021-10-22 17:37:49 | Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber |
Previous Message | Bossart, Nathan | 2021-10-22 16:58:18 | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function? |