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 fd1fce0f-5989-2563-5fa0-c2402cf8b2b0@enterprisedb.com
Whole thread Raw
In response to Re: pgcon unconference / impact of block size on performance  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgcon unconference / impact of block size on performance
List pgsql-hackers
On 6/7/22 18:26, Robert Haas wrote:
> On Sat, Jun 4, 2022 at 7:23 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>> This opened a long discussion about possible explanations - I claimed
>> one of the main factors is the adoption of flash storage, due to pretty
>> fundamental differences between HDD and SSD systems. But the discussion
>> concluded with an agreement to continue investigating this, so here's an
>> attempt to support the claim with some measurements/data.
> 
> Interesting. I wonder if the fact that x86 machines have a 4kB page
> size matters here. It seems hard to be sure because it's not something
> you can really change. But there are a few of your graphs where 4kB
> spikes up above any higher or lower value, and maybe that's why?
>

Possibly, but why would that be the case? Maybe there are places that do
stuff with memory and have different optimizations based on length? I'd
bet the 4k page is way more optimized than the other cases.

But honestly, I think the SSD page size matters much more, and the main
bump between 4k and 8k comes from having to deal with just a single
page. Imagine you write 8k postgres page - the filesystem splits that
into two 4k pages, and then eventually writes them to storage. It may
happen the writeback flushes them separately, possibly even to different
places on the device. Which might be more expensive to read later, etc.

I'm just speculating, of course. Maybe the storage is smarter and can
figure some of this internally, or maybe the locality will remain high.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Invalid memory access in pg_stat_get_subscription
Next
From: Peter Geoghegan
Date:
Subject: Re: An inverted index using roaring bitmaps