Re: pg_restore taking 4 hours!

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-performance by date

  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!