Re: Configuring PostgreSQL to minimize impact of checkpoints - Mailing list pgsql-performance

From jao@geophile.com
Subject Re: Configuring PostgreSQL to minimize impact of checkpoints
Date
Msg-id 1084389767.40a27987437da@geophile.com
Whole thread Raw
In response to Re: Configuring PostgreSQL to minimize impact of checkpoints  (Vivek Khera <khera@kcilink.com>)
Responses Re: Configuring PostgreSQL to minimize impact of checkpoints  (Vivek Khera <khera@kcilink.com>)
List pgsql-performance
Quoting Vivek Khera <khera@kcilink.com>:

> >>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> TL> Jack Orenstein <jao@geophile.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.

pgsql-performance by date:

Previous
From: Vivek Khera
Date:
Subject: Re: Configuring PostgreSQL to minimize impact of
Next
From: Vivek Khera
Date:
Subject: Re: Configuring PostgreSQL to minimize impact of checkpoints