Re: Fsync IO issue

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: ProfiVPS Support <support(at)profivps(dot)hu>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Fsync IO issue
Date: 2023-05-30 20:56:36
Message-ID: CAHyXU0yVjpHZoz0V2AgNoFQfQeGStrLYKABOPA19PdyOC-xYnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, May 4, 2023 at 4:23 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Fri, May 5, 2023 at 8:37 AM ProfiVPS Support <support(at)profivps(dot)hu>
> wrote:
> > I feel like ANYTHING would be better than this. Even risking loosing
> _some_ of the latest data in case of a server crash (if it crashes we lose
> data anyways until restart, ofc we could have HA I know and we will when
> there'll be a need) .
>
> Try synchronous_commit=off:
>
> https://www.postgresql.org/docs/current/wal-async-commit.html

Yeah, or batch multiple inserts into a transaction somehow. In the worst
case, each insert can cause multiple things to happen, write to WAL, flush
to heap (8k write), commit bit set (another 8k write), etc. In most
workloads these steps can aggregate together in various ways but not
always.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bob Jolliffe 2023-05-31 08:43:42 Unaccounted regression from postgresql 11 in later versions
Previous Message Ranier Vilela 2023-05-23 19:56:20 Re: PostgreSQL performance on ARM i.MX6