Re: Refactoring the checkpointer's fsync request queue - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Refactoring the checkpointer's fsync request queue
Date
Msg-id 20190122210152.gfeak6basvbvfkon@alap3.anarazel.de
Whole thread Raw
In response to Re: Refactoring the checkpointer's fsync request queue  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
Hi,

On 2019-01-22 14:53:11 -0600, Kevin Grittner wrote:
> On Tue, Jan 22, 2019 at 2:38 PM Andres Freund <andres@anarazel.de> wrote:
> 
> > close() doesn't trigger an fsync() in general
> 
> What sort of a performance hit was observed when testing the addition
> of fsync or fdatasync before any PostgreSQL close() of a writable
> file, or have we not yet checked that?

I briefly played with it, and it was so atrocious (as in, less than
something like 0.2x the throughput) that I didn't continue far down that
path.  Two ways I IIRC (and it's really just memory) I tried were:

a) Short lived connections that do a bunch of writes to files each. That
   turns each disconnect into an fsync of most files.
b) Workload with > max_files_per_process files (IIRC I just used a bunch
   of larger tables with a few indexes each) in a read/write workload
   that's a bit larger than shared buffers. That lead to most file
   closes being integrity writes, with obvious downsides.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Refactoring the checkpointer's fsync request queue
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well