MIME-Version: 1.0
References: <df8a9898-0ff9-4805-abc2-f469670ce92d@exa.co.za>
 <CAKAnmmKXs4vpUt-3ML2H4rE4+3MEpHqG-rJVqvLqyaW0rfs3Jg@mail.gmail.com>
 <7601f762-3449-4e66-9634-6f40afdc9b8f@exa.co.za>
In-Reply-To: <7601f762-3449-4e66-9634-6f40afdc9b8f@exa.co.za>
From: Merlin Moncure <mmoncure@gmail.com>
Date: Tue, 10 Mar 2026 17:07:30 -0600
Message-ID: 
 <CAHyXU0zKGjv5BKKPfycY1o5fpQpRkyDYKyvmpTRn5Di2n9aVeg@mail.gmail.com>
Subject: Re: Postgres IO sweet spot
To: Riaan Stander <rstander@exa.co.za>
Cc: pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000002f5a42064cb3960d"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHyXU0zKGjv5BKKPfycY1o5fpQpRkyDYKyvmpTRn5Di2n9aVeg%40mail.gmail.com>
Precedence: bulk

--0000000000002f5a42064cb3960d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 17, 2026 at 4:42=E2=80=AFPM Riaan Stander <rstander@exa.co.za> =
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

--0000000000002f5a42064cb3960d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Tue, Feb 17, 2026 at 4:42=E2=80=AFPM Riaan Stander=
 &lt;<a href=3D"mailto:rstander@exa.co.za">rstander@exa.co.za</a>&gt; wrote=
:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>That&#39;s an expensive way to provide some HA. What&#39;s t=
he
            business requirement? How does that tie into Postgres? Might
            be able to do it in other ways.</div>
        </div>
      </div>
    </blockquote>
    We used to run a SAN shared between our host servers, but this was
    replaced with Storage Spaces. I think they don&#39;t trust Postgres
    native HA capabilities and want some hardware guarantee.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>Yikes! Yes, SSD would be a big win. It&#39;s orders of
            magnitude faster, and just removes so many problems.</div>
        </div>
      </div>
    </blockquote>
    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&#39;m
    trying to get them to rather deploy direct attached NVME/SSD to each
    Host and then use PG HA from there.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    It does take a lot of convincing and arguing though, so concrete
    number help get the point across.<br>
    <br>
    Thanks for the response<br></div></blockquote><div><br></div><div>Spinn=
ing disks+cache=C2=A0 was the most common configuration before SSD came alo=
ng.=C2=A0 Burst performance is great but if you overwhelm the cache, write =
performance can fall off a cliff.=C2=A0 This sounds like exactly what is ha=
ppening to you; moving backups off just bought you some time.=C2=A0 Direct =
attached SSD will completely smoke your current setup.</div><div><br></div>=
<div>&gt; I think they don&#39;t trust Postgres native HA capabilities and =
want some hardware guarantee.</div><div><br></div><div>What is this, 2005?=
=C2=A0 Properly configured HS/SR setups are incredibly robust and are the d=
efault configuration for amazon RDS and many, many other platforms.=C2=A0 R=
eading between the lines here, it sounds like your storage team bought over=
priced garbage and is refusing to admit it&#39;s not getting the job done.=
=C2=A0 Postgres failover gets tested routinely across a vast array of syste=
ms, how many times has your exact configuration been tested?</div><div><br>=
</div><div>Is your storage shared with other systems?=C2=A0 Do you have any=
 pgbench numbers for reference?=C2=A0 What are your commit rates?=C2=A0 (se=
e=C2=A0xact_commit in pg_stat_database, tracked over time)</div><div><br></=
div><div>merlin</div></div></div>

--0000000000002f5a42064cb3960d--