From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Reduce initial size of RelfilenodeMapHash. |
Date: | 2017-05-12 22:30:29 |
Message-ID: | E1d9J4v-0008Cg-Qd@gemulon.postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Reduce initial size of RelfilenodeMapHash.
A test case provided by Mathieu Fenniak shows that hash_seq_search'ing
this hashtable can consume a very significant amount of overhead during
logical decoding, which triggers frequent cache invalidation. Testing
suggests that the actual population of the hashtable is often no more
than a few dozen entries, so we can cut the overhead just by dropping
the initial number of buckets down from 1024 --- I chose to cut it to 64.
(In situations where we do have a significant number of entries, we
shouldn't get any real penalty from doing this, as the dynahash.c code
will resize the hashtable automatically.)
This gives a further factor-of-two savings in Mathieu's test case.
That may be overly optimistic for real-world benefit, as real cases
may have larger average table populations, but it's hard to see it
turning into a net negative for any workload.
Back-patch to 9.4 where relfilenodemap.c was introduced.
Discussion: https://postgr.es/m/CAHoiPjzea6N0zuCi=+f9v_j94nfsy6y8SU7-=bp4=7qw6_i=Rg@mail.gmail.com
Branch
------
REL9_6_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f7d0a31ce94e78d8e69a5e2cc8ae44344d85f9db
Modified Files
--------------
src/backend/utils/cache/relfilenodemap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2017-05-12 22:32:11 | pgsql: doc: update markup for release note "release date" block |
Previous Message | Alvaro Herrera | 2017-05-12 22:25:27 | pgsql: getObjectDescription: support extended statistics |