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
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 updat
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 a
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 curre
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
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 a
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 ju
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 t
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 rec
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
whethe
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 broadc
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
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? Becau
13 matches
Mail list logo
