From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Checkpoint question |
Date: | 2006-01-13 18:40:25 |
Message-ID: | 20060113184025.GI9017@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 other workloads more) and is seeing a
> > pretty high rate of buffer updates (meaning that we'd likely do a bunch
> > of extra work as part of the checkpoint if we didn't take note of
> > exactly what buffers needed to be flushed). Unfortunately I don't think
> > there's any way for the backend to know much about either condition
> > right now, so it couldn't decide when it made sense to make a list of
> > buffers to flush. Maybe in the future...
> >
>
> The senario you mentioned is happened in many OLTP applications. No need
> for backend to know this -- we can leave the decision to the DBA:
> CHECKPOINT FULL or CHECPOINT PARTIAL. If you got some machines can observe
> its CHECKPOINT duration, that would be sweet.
Maybe I'm missing something here, but wouldn't that only help if you
were manually issuing checkpoints?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-01-13 19:18:29 | Re: Improving N-Distinct estimation by ANALYZE |
Previous Message | Magnus Hagander | 2006-01-13 18:21:46 | Re: PostgreSQL win32 & NT4 |