Re: pgcon unconference / impact of block size on performance
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>, Bruce Momjian <bruce@momjian.us>
Date: 2022-06-13T16:05:38Z
Lists: pgsql-hackers
Attachments
- report-3.png (image/png)
On 6/13/22 17:42, Merlin Moncure wrote: > On Sat, Jun 4, 2022 at 6:23 PM Tomas Vondra > <tomas.vondra@enterprisedb.com <mailto:tomas.vondra@enterprisedb.com>> > wrote: > > Hi, > > 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. > > > Wow. Random numbers are fantastic, Significant reduction in sequential > throughput is a little painful though, I see 40% reduction in some cases > if I'm reading that right. Any thoughts on why that's the case? Are > there mitigations possible? > I think you read that right - given a fixed I/O depth, the throughput for sequential access gets reduced. Consider for example the attached chart with sequential read/write results for the Optane 900P. The IOPS increases for smaller blocks, but not enough to compensate for the bandwidth drop. Regarding the mitigations - I think prefetching (read-ahead) should do the trick. Just going to iodepth=2 mostly makes up for the bandwidth difference. You might argue prefetching would improve the random I/O results too, but I don't think that's the same thing - read-ahead for sequential workloads is much easier to implement (even transparently). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company