Re: [HACKERS] WAL logging freezing - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] WAL logging freezing
Date
Msg-id 22033.1162258828@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] WAL logging freezing  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: [HACKERS] WAL logging freezing  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-patches
"Simon Riggs" <simon@2ndquadrant.com> writes:
> That was understood; in the above example I agree you need to flush. If
> you don't pass a truncation point, you don't need to flush whether or
> not you actually truncate. So we don't need to flush *every* time,

OK, but does that actually do much of anything for your performance
complaint?  Just after GlobalXmin has passed a truncation point, *every*
vacuum the system does will start performing a flush-n-fsync, which
seems like exactly what you didn't like.  If the syncs were spread out
in time for different rels then maybe this idea would help, but AFAICS
they won't be.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: --single-transaction doc clarification
Next
From: Neil Conway
Date:
Subject: Re: --single-transaction doc clarification