Re: Setting BLCKSZ 4kB

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: sanyam jain <sanyamjain22(at)live(dot)in>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Setting BLCKSZ 4kB
Date: 2018-01-26 13:56:01
Message-ID: 20180126135601.GI20836@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 17, 2018 at 02:10:10PM +0100, Fabien COELHO wrote:
>
> Hello,
>
> >What are the cons of setting BLCKSZ as 4kB? When saw the results published
> >on [...].
>
> There were other posts and publications which points to the same direction
> consistently.
>
> This matches my deep belief is that postgres default block size is a
> reasonable compromise for HDD, but is less pertinent for SSD for most OLTP
> loads.
>
> For OLAP, I do not think it would lose much, but I have not tested it.
>
> >Does turning off FPWs will be safe if BLCKSZ is set to 4kB given page size
> >of file system is 4kB?
>
> FPW = Full Page Write. I would not bet on turning off FPW, ISTM that SSDs
> can have "page" sizes as low as 512 bytes, but are typically 2 kB or 4 kB,
> and the information easily available anyway.

Yes, that is the hard part, making sure you have 4k granularity of
write, and matching write alignment. pg_test_fsync and diskchecker.pl
(which we mention in our docs) will not help here. A specific alignment
test based on diskchecker.pl would have to be written. However, if you
look at the kernel code you might be able to verify quickly that the 4k
atomicity is not guaranteed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-01-26 13:58:58 Re: [HACKERS] WIP: Aggregation push-down
Previous Message a.parfenov 2018-01-26 13:54:08 Configuring messages language on Windows