From: | Ants Aasma <ants(dot)aasma(at)cybertec(dot)at> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hash_search_with_hash_value is high in "perf top" on a replica |
Date: | 2025-02-01 14:43:41 |
Message-ID: | CANwKhkO0WJpp147eSmdiHU9KobqhkHzMi0+DR-TWz8FM7jMHVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 31, 2025, 15:43 Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Maybe it's a red herring though, but it looks pretty suspicious.
>
> It's unfortunately not too surprising - our buffer mapping table is a
> pretty
> big bottleneck. Both because a hash table is just not a good fit for the
> buffer mapping table due to the lack of locality and because dynahash is
> really poor hash table implementation.
>
I measured similar things when looking at apply throughput recently. For
in-cache workloads buffer lookup and locking was about half of the load.
One other direction is to extract more memory concurrency. Prefetcher could
batch multiple lookups together so CPU OoO execution has a chance to fire
off multiple memory accesses at the same time.
The other direction is to split off WAL decoding, buffer lookup and maybe
even pinning to a separate process from the main redo loop.
--
Ants Aasma
>
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-02-01 15:01:22 | Re: NOT ENFORCED constraint feature |
Previous Message | Zhang Mingli | 2025-02-01 13:39:10 | Re: Proposal to CREATE FOREIGN TABLE LIKE |