Re: Adding basic NUMA awareness
Greg Burd <greg@burd.me>
From: Greg Burd <greg@burd.me>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas@vondra.me>, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>, Dmitry Dolgov
<9erthalion6@gmail.com>
Date: 2025-07-09T16:55:51Z
Lists: pgsql-hackers
On Jul 9 2025, at 12:35 pm, Andres Freund <andres@anarazel.de> wrote: > FWIW, I've started to wonder if we shouldn't just get rid of the freelist > entirely. While clocksweep is perhaps minutely slower in a single > thread than > the freelist, clock sweep scales *considerably* better [1]. As it's rather > rare to be bottlenecked on clock sweep speed for a single thread > (rather then > IO or memory copy overhead), I think it's worth favoring clock sweep. Hey Andres, thanks for spending time on this. I've worked before on freelist implementations (last one in LMDB) and I think you're onto something. I think it's an innovative idea and that the speed difference will either be lost in the noise or potentially entirely mitigated by avoiding duplicate work. > Also needing to switch between getting buffers from the freelist and > the sweep > makes the code more expensive. I think just having the buffer in the sweep, > with a refcount / usagecount of zero would suffice. If you're not already coding this, I'll jump in. :) > That seems particularly advantageous if we invest energy in making the clock > sweep deal well with NUMA systems, because we don't need have both a NUMA > aware freelist and a NUMA aware clock sweep. 100% agree here, very clever approach adapting clock sweep to a NUMA world. best. -greg > > Greetings, > > Andres Freund
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Sort guc_parameters.dat alphabetically by name
- fce7c73fba4e 19 (unreleased) cited