| 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
| 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 |