From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: pgcon unconference / impact of block size on performance |
Date: | 2022-06-06 22:39:53 |
Message-ID: | CAApHDvpYg+ZOQTpAbgg3s+d6faxUwywwNm5Gf8XhTphfjohx6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 5 Jun 2022 at 11:23, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smaller (4k) data pages.
A few years ago when you and I were doing analysis into the TPC-H
benchmark, we found that larger page sizes helped various queries,
especially Q1. It would be good to see what the block size changes in
performance in a query such as: SELECT sum(value) FROM
table_with_tuples_of_several_hundred_bytes;. I don't recall the
reason why 32k pages helped there, but it seems reasonable that doing
more work for each lookup in shared buffers might be 1 reason.
Maybe some deeper analysis into various workloads might convince us
that it might be worth having an initdb option to specify the
blocksize. There'd be various hurdles to get over in the code to make
that work. I doubt we could ever make the default smaller than it is
today as it would nobody would be able to insert rows larger than 4
kilobytes into a table anymore. Plus pg_upgrade issues.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2022-06-06 23:21:18 | Re: replacing role-level NOINHERIT with a grant-level option |
Previous Message | David Rowley | 2022-06-06 21:27:45 | Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list |