Re: Configuring PostgreSQL to minimize impact of checkpoints
Jack Orenstein <jao@geophile.com>
From: jao@geophile.com
To: Vivek Khera <khera@kcilink.com>
Cc: pgsql-performance@postgresql.org
Date: 2004-05-12T19:22:47Z
Lists: 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.