From: | jordani(at)go-link(dot)net |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com |
Subject: | Re: Incremental checkopints |
Date: | 2011-08-04 02:24:05 |
Message-ID: | be77a220edf3ed7b245f53aceb0ad86f.squirrel@mail.go-link.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-08-04 05:59:07 | Re: Further news on Clang - spurious warnings |
Previous Message | Robert Haas | 2011-08-04 01:59:57 | Re: mosbench revisited |