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

From Tomas Vondra
Subject Re: pgcon unconference / impact of block size on performance
Date
Msg-id a5254b8d-62c3-fec7-5a6b-f8ea47f0e064@enterprisedb.com
Whole thread Raw
In response to Re: pgcon unconference / impact of block size on performance  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
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
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pltcl crash on recent macOS
Next
From: Aleksander Alekseev
Date:
Subject: Re: better page-level checksums