From: | jao(at)geophile(dot)com |
---|---|
To: | Vivek Khera <khera(at)kcilink(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Configuring PostgreSQL to minimize impact of checkpoints |
Date: | 2004-05-12 19:22:47 |
Message-ID: | 1084389767.40a27987437da@geophile.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Quoting Vivek Khera <khera(at)kcilink(dot)com>:
> >>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> TL> Jack Orenstein <jao(at)geophile(dot)com> writes:
> >> I'm looking at one case in which two successive transactions, each
> >> updating a handful of records, take 26 and 18 *seconds* (not msec) to
> >> complete. These transactions normally complete in under 30 msec.
>
> TL> I've seen installations in which it seemed that the "normal" query load
> TL> was close to saturating the available disk bandwidth, and the extra load
> TL> imposed by a background VACUUM just pushed the entire system's response
> TL> time over a cliff. In an installation that has I/O capacity to spare,
> ...
> TL> I suspect that the same observations hold true for checkpoints, though
> TL> I haven't specifically seen an installation suffering from that effect.
>
> I don't see that. But I also set checkpoint segments to about 50 on
> my big server.
But wouldn't that affect checkpoint frequency, not checkpoint cost?
Jack Orenstein
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2004-05-12 19:29:11 | Re: Configuring PostgreSQL to minimize impact of checkpoints |
Previous Message | Vivek Khera | 2004-05-12 19:05:05 | Re: Configuring PostgreSQL to minimize impact of |