Re: Adding basic NUMA awareness

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Alexey Makhmutov <a(dot)makhmutov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding basic NUMA awareness
Date: 2026-01-13 00:10:00
Message-ID: zndz3dlmp7xlypczxjbwdfrey3masto6vuwpnzjvgunslprv25@rucfkdgfpb4p
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-01-13 00:58:49 +0100, Tomas Vondra wrote:
> On 1/10/26 02:42, Andres Freund wrote:
> > psql -Xq -c 'SELECT pg_buffercache_evict_all();' -c 'SELECT numa_node, sum(size) FROM pg_shmem_allocations_numa GROUP BY 1;' && perf stat --per-socket -M memory_bandwidth_read,memory_bandwidth_write -a psql -c 'SELECT sum(abalance) FROM pgbench_accounts;'

> And then I initialized pgbench with scale that is much larger than
> shared buffers, but fits into RAM. So cached, but definitely > NB/4. And
> then I ran
>
> select * from pgbench_accounts offset 1000000000;
>
> which does a sequential scan with the circular buffer you mention abobe

Did you try it with the query I suggested? One plausible reason why you did
not see an effect with your query is that with a huge offset you actually
never deform the tuple, which is an important and rather latency sensitive
path.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2026-01-13 00:20:28 Re: docs: clarify ALTER TABLE behavior on partitioned tables
Previous Message Tomas Vondra 2026-01-12 23:58:49 Re: Adding basic NUMA awareness