| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Greg Burd <greg(at)burd(dot)me>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Subject: | Re: Adding basic NUMA awareness |
| Date: | 2025-07-11 16:06:13 |
| Message-ID: | wgzckgqvchpjca26v2dhxw5qjuz4qhwqenfth37mxafcjhgr6i@jonu5kckupzo |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-07-10 17:31:45 +0200, Tomas Vondra wrote:
> On 7/9/25 19:23, Andres Freund wrote:
> > There's other things around this that could use some attention. It's not hard
> > to see clock sweep be a bottleneck in concurrent workloads - partially due to
> > the shared maintenance of the clock hand. A NUMAed clock sweep would address
> > that. However, we also maintain StrategyControl->numBufferAllocs, which is a
> > significant contention point and would not necessarily be removed by a
> > NUMAificiation of the clock sweep.
> >
>
> Wouldn't it make sense to partition the numBufferAllocs too, though? I
> don't remember if my hacky experimental patch NUMA-partitioning did that
> or I just thought about doing that, but why wouldn't that be enough?
It could be solved together with partitioning, yes - that's what I was trying
to reference with the emphasized bit in "would *not necessarily* be removed by
a NUMAificiation of the clock sweep".
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-07-11 16:14:06 | Re: Adding basic NUMA awareness |
| Previous Message | Andres Freund | 2025-07-11 15:59:39 | Re: Adding wait events statistics |