>>>>> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
TL> Jack Orenstein <[EMAIL PROTECTED]> 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, me stand up waving hand... ;-) This is my only killer problem left. I always peg my disk usage at 100% when vacuum runs, and other queries are slow too. When not running vacuum, my queries are incredibly zippy fast, including joins and counts and group by's on upwards of 100k rows at a time. 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. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-869-4449 x806 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
