Re: Spreading full-page writes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Spreading full-page writes
Date
Msg-id CA+U5nMJnb9Cpv2Tp5VAG8bw=NZw1Qea9tfuRWnvhdQDW3L+PuQ@mail.gmail.com
Whole thread Raw
In response to Spreading full-page writes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Spreading full-page writes  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 25 May 2014 17:52, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:

> Here's an idea I tried to explain to Andres and Simon at the pub last night,
> on how to reduce the spikes in the amount of WAL written at beginning of a
> checkpoint that full-page writes cause. I'm just writing this down for the
> sake of the archives; I'm not planning to work on this myself.
...

Thanks for that idea, and dinner. It looks useful.

I'll call this idea "Background FPWs"

> Now, I'm sure there are issues with this scheme I haven't thought about, but
> I wanted to get this written down. Note this does not reduce the overall WAL
> volume - on the contrary - but it ought to reduce the spike.

The requirements we were discussing were around

A) reducing WAL volume
B) reducing foreground overhead of writing FPWs - which spikes badly
after checkpoint and the overhead is paid by the user processes
themselves
C) need for FPWs during base backup

So that gives us a few approaches

* Compressing FPWs gives A
* Background FPWs gives us B  which look like we can combine both ideas

* Double-buffering would give us A and B, but not C  and would be incompatible with other two ideas

Will think some more.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Race condition within _bt_findinsertloc()? (new page split code)
Next
From: ash
Date:
Subject: Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?