PGSQL PERFORMANCE 14 RE PG RESTORE TAKING 4 HOURS
From: josh@no-spam (Josh Berkus)
Subject: Re: pg_restore taking 4 hours!
Date: Mon, 13 Dec 2004 10:25:54 -0800


Vivek,

> The biggest improvement in speed to restore time I have discovered is > to increase the checkpoint segments.  I bump mine to about 50.  And > moving the pg_xlog to a separate physical disk helps a lot there, too.

Don't leave it at 50; if you have the space on your log array, bump it up to 256.

-- Josh Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org






From: josh@no-spam (Josh Berkus)
Subject: Re: pg_restore taking 4 hours!
Date: Mon, 13 Dec 2004 10:43:28 -0800

Vivek,

> Do I need a correspondingly large checkpoint timeout then? Or does > that matter much?

Yes, you do.

> And does this advice apply if the pg_xlog is on the same RAID partition > (mine currently is not, but perhaps will be in the future)

Not as much, but it's still a good idea to serialize the load. With too few segments, you get a pattern like:

Fill up segments Write to database Recycle segments Fill up segments Write to database Recycle segments etc.

Compared to doing it in one long run of a single cycle, considerble efficiency is lost. With a proper 2-array setup, the segments become like a write buffer for the database, and you want that buffer as large as you can afford in order to prevent buffer cycling from interrupting database writes.

BTW, for members of the studio audience, checkpoint_segments of 256 is about 8GB.

-- Josh Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@no-spam so that your message can get through to the mailing list cleanly