Re: Incremental checkopints - Mailing list pgsql-hackers

From jordani@go-link.net
Subject Re: Incremental checkopints
Date
Msg-id be77a220edf3ed7b245f53aceb0ad86f.squirrel@mail.go-link.net
Whole thread Raw
In response to Incremental checkopints  (jordani@go-link.net)
List pgsql-hackers
I have not explained well what I have in my mind in first message.

Main goal is more buffers to stay dirty in memory for longer time. So
checkpoint segments have to be 2, 3... times than in current approach. And
separate parameter can control how much buffers to write at once. DBA can
tune:
- checkpoint segments - higher number for less writes but more time for
crash recovery;
- (how much buffers to write at once) - more for throughput and less for
latency.

> I think what we'd need to track is the LSN that first dirtied the page
> (as opposed to the current field, which tracks the LSN that most
> recently wrote the page).  If we write and flush all pages whose
> first-dirtied LSN precedes some cutoff point, then we ought to be able
> to advance the redo pointer to that point.

Also if the page is written by backend LSN_first_dirtied have to be cleared.

I believe (but I can not prove) it worths testing and advantage will be
noticeable.

Jordan Ivanov



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Further news on Clang - spurious warnings
Next
From: Robert Haas
Date:
Subject: Re: mosbench revisited