Re: hash_search_with_hash_value is high in "perf top" on a replica

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

>

In response to

Responses

Browse pgsql-hackers by date

  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