On Thu, Jan 12, 2006 at 05:00:49PM -0500, Qingqing Zhou wrote:
On Thu, 12 Jan 2006, Jim C. Nasby wrote:
It sounds like worrying about this would be much more interesting on a
machine that is seeing both a fairly heavy IO load (meaning checkpoint
will both take longer and affect
On Wed, 2006-01-11 at 20:46 -0500, Qingqing Zhou wrote:
On Wed, 11 Jan 2006, Simon Riggs wrote:
Probably good idea to read Gray Reuter or Vekum Vossen books on
transactional systems theory before any such discussion.
So can you give me some hints why my thoughts are just wrong?
On Wed, 2006-01-11 at 22:33 -0500, Qingqing Zhou wrote:
On Wed, 11 Jan 2006, Tom Lane wrote:
It'd be possible to do something like this: after establishing
RedoRecPtr, make one quick pass through the buffers and make a list of
what needs to be dumped at that instant. Then go back and do
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 11 Jan 2006, Tom Lane wrote:
It'd be possible to do something like this: after establishing
RedoRecPtr, make one quick pass through the buffers and make a list of
what needs to be dumped at that instant. Then go back and do the actual
I/O for
On Thu, 12 Jan 2006, Simon Riggs wrote:
The only buffers this will miss are ones that were clean throughout the
whole of the last checkpoint cycle, yet have been dirtied between the
start of the checkpoint pass and when the pass reaches it.
I agree on the analysis but I am not sure current
On Thu, Jan 12, 2006 at 04:50:30AM -0500, Qingqing Zhou wrote:
On Thu, 12 Jan 2006, Simon Riggs wrote:
The only buffers this will miss are ones that were clean throughout the
whole of the last checkpoint cycle, yet have been dirtied between the
start of the checkpoint pass and when
On Thu, 12 Jan 2006, Jim C. Nasby wrote:
It sounds like worrying about this would be much more interesting on a
machine that is seeing both a fairly heavy IO load (meaning checkpoint
will both take longer and affect other workloads more) and is seeing a
pretty high rate of buffer updates
I understand checkpoint code doing something like this:
Get RedoRecPtr;
Flush all dirty buffers no matter what's its LSN;
Write down checkpoint xlog record;
So I wonder is it possible flush only dirty buffers with LSN RedoRecPtr
to improve checkpoint caused delay?
On Wed, 2006-01-11 at 18:24 -0500, Qingqing Zhou wrote:
I understand checkpoint code doing something like this:
Get RedoRecPtr;
Flush all dirty buffers no matter what's its LSN;
Write down checkpoint xlog record;
So I wonder is it possible flush only dirty buffers with
On Wed, 11 Jan 2006, Simon Riggs wrote:
Probably good idea to read Gray Reuter or Vekum Vossen books on
transactional systems theory before any such discussion.
So can you give me some hints why my thoughts are just wrong?
Regards,
Qingqing
---(end of
Qingqing Zhou [EMAIL PROTECTED] writes:
So I wonder is it possible flush only dirty buffers with LSN RedoRecPtr
to improve checkpoint caused delay?
Certainly not. If LSN RedoRecPtr then you know the buffer contains
some changes more recent than the checkpoint, but you cannot tell
whether it
On Wed, 11 Jan 2006, Tom Lane wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
So I wonder is it possible flush only dirty buffers with LSN RedoRecPtr
to improve checkpoint caused delay?
Certainly not. If LSN RedoRecPtr then you know the buffer contains
some changes more recent than
On Wed, 11 Jan 2006, Tom Lane wrote:
It'd be possible to do something like this: after establishing
RedoRecPtr, make one quick pass through the buffers and make a list of
what needs to be dumped at that instant. Then go back and do the actual
I/O for only those buffers. I'm dubious that
13 matches
Mail list logo
