public inbox for [email protected]  

help / color / mirror / Atom feed

From: Merlin Moncure <[email protected]>
To: Riaan Stander <[email protected]>
Cc: [email protected]
Subject: Re: Postgres IO sweet spot
Date: Tue, 10 Mar 2026 17:07:30 -0600
Message-ID: <CAHyXU0zKGjv5BKKPfycY1o5fpQpRkyDYKyvmpTRn5Di2n9aVeg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAKAnmmKXs4vpUt-3ML2H4rE4+3MEpHqG-rJVqvLqyaW0rfs3Jg@mail.gmail.com>
	<[email protected]>

On Tue, Feb 17, 2026 at 4:42 PM Riaan Stander <[email protected]> wrote:

> That's an expensive way to provide some HA. What's the business
> requirement? How does that tie into Postgres? Might be able to do it in
> other ways.
>
> We used to run a SAN shared between our host servers, but this was
> replaced with Storage Spaces. I think they don't trust Postgres native HA
> capabilities and want some hardware guarantee.
>
> Yikes! Yes, SSD would be a big win. It's orders of magnitude faster, and
> just removes so many problems.
>
> I assume it will help, but I fear however that the overhead with a 3 way
> mirror is not going to be solved with just adding SSD. I'm trying to get
> them to rather deploy direct attached NVME/SSD to each Host and then use PG
> HA from there.
>
> Sorry, I have no numbers to provide you there, but I cannot imagine any
> amount of tuning is going to be as big a win as going to SSD.
>
> It does take a lot of convincing and arguing though, so concrete number
> help get the point across.
>
> Thanks for the response
>

Spinning disks+cache  was the most common configuration before SSD came
along.  Burst performance is great but if you overwhelm the cache, write
performance can fall off a cliff.  This sounds like exactly what is
happening to you; moving backups off just bought you some time.  Direct
attached SSD will completely smoke your current setup.

> I think they don't trust Postgres native HA capabilities and want some
hardware guarantee.

What is this, 2005?  Properly configured HS/SR setups are incredibly robust
and are the default configuration for amazon RDS and many, many other
platforms.  Reading between the lines here, it sounds like your storage
team bought overpriced garbage and is refusing to admit it's not getting
the job done.  Postgres failover gets tested routinely across a vast array
of systems, how many times has your exact configuration been tested?

Is your storage shared with other systems?  Do you have any pgbench numbers
for reference?  What are your commit rates?  (see xact_commit in
pg_stat_database, tracked over time)

merlin

view thread (5+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Postgres IO sweet spot
  In-Reply-To: <CAHyXU0zKGjv5BKKPfycY1o5fpQpRkyDYKyvmpTRn5Di2n9aVeg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox