| From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| 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-12 22:00:49 |
| Message-ID: | Pine.LNX.4.58.0601121658460.17828@tox.db |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2006-01-12 22:46:04 | Contrib Schemas |
| Previous Message | Jim C. Nasby | 2006-01-12 21:53:09 | Re: Checkpoint question |