Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance - Mailing list pgsql-general

From Pierre Barre
Subject Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance
Date
Msg-id dd5254f2-a308-4520-888e-e4f49a81a6ed@app.fastmail.com
Whole thread Raw
In response to Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance  (Jeff Ross <jross@openvistas.net>)
List pgsql-general
Hi all,

Circling back on this thread, ZeroFS now supports placing its WAL on local storage (or something like S3 Express One
Zone).ZeroFS wal is sub-gigabyte and just there to handle frequent syncs, it doesn't act as writeback caching. 

Here are pgbench results with synchronous_commit = on, WAL on local NVMe, on a 6-core / 32GB RAM machine with a 4 Gb/s
pipe:

$ pgbench -c 100 -T 100 --protocol=prepared

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: prepared
number of clients: 100
number of threads: 1
duration: 100 s
number of transactions actually processed: 1,578,675
number of failed transactions: 0 (0.000%)
latency average = 6.312 ms
tps = 15,843 (without initial connection time)

Best,
Pierre

On Fri, Jul 25, 2025, at 00:03, Jeff Ross wrote:
> On 7/24/25 13:50, Pierre Barre wrote:
>
>> It’s not “safe” or “unsafe”, there’s mountains of valid workloads which don’t require synchronous_commit.
Synchronous_commitdon’t make your system automatically safe either, and if that’s a requirement, there’s many
workarounds,as you suggested, it certainly doesn’t make the setup useless. 
>>
>> Best,
>> Pierre
>>
>> On Thu, Jul 24, 2025, at 21:44, Nico Williams wrote:
>>> On Fri, Jul 18, 2025 at 12:57:39PM +0200, Pierre Barre wrote:
>>>> - Postgres configured accordingly memory-wise as well as with
>>>>    synchronous_commit = off, wal_init_zero = off and wal_recycle = off.
>>> Bingo.  That's why it's fast (synchronous_commit = off).  It's also why
>>> it's not safe _unless_ you have a local, fast, persistent ZIL device
>>> (which I assume you don't).
>>>
>>> Nico
>>> --
> This then begs the obvious question of how fast is this with
> synchronous_commit = on?



pgsql-general by date:

Previous
From: yudhi s
Date:
Subject: Re: Question on execution plan and suitable index
Next
From: Laurenz Albe
Date:
Subject: Re: Question on execution plan and suitable index