Re: pgcon unconference / impact of block size on performance - Mailing list pgsql-hackers

From David Rowley
Subject Re: pgcon unconference / impact of block size on performance
Date
Msg-id CAApHDvpYg+ZOQTpAbgg3s+d6faxUwywwNm5Gf8XhTphfjohx6w@mail.gmail.com
Whole thread Raw
In response to pgcon unconference / impact of block size on performance  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses RE: pgcon unconference / impact of block size on performance
List pgsql-hackers
On Sun, 5 Jun 2022 at 11:23, Tomas Vondra <tomas.vondra@enterprisedb.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

[1] https://www.postgresql.org/docs/current/limits.html



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
Next
From: Stephen Frost
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option