From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, Vivek Khera <khera(at)kcilink(dot)com> |
Subject: | Re: pg_restore taking 4 hours! |
Date: | 2004-12-13 19:21:04 |
Message-ID: | 27280.1102965664@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 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.
Actually I think the problem is specifically that you get checkpoints
too often if either checkpoint_timeout or checkpoint_segments is too
small. A checkpoint is expensive both directly (the I/O it causes)
and indirectly (because the first update of a particular data page
after a checkpoint causes the whole page to be logged in WAL). So
keeping them spread well apart is a Good Thing, as long as you
understand that a wider checkpoint spacing implies a longer time to
recover if you do suffer a crash.
I think 8.0's bgwriter will considerably reduce the direct cost of
a checkpoint (since not so many pages will be dirty when the checkpoint
happens) but it won't do a thing for the indirect cost.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-12-13 19:35:31 | Re: subscribe missing? |
Previous Message | Bruno Wolff III | 2004-12-13 19:11:07 | Re: table with sort_key without gaps |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Nunes Melo | 2004-12-13 19:32:02 | Re: Similar tables, different indexes performance |
Previous Message | Josh Berkus | 2004-12-13 18:43:28 | Re: pg_restore taking 4 hours! |