Re: restore time: sort_mem vs. checkpoing_segments - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: restore time: sort_mem vs. checkpoing_segments
Date
Msg-id 200309231359.h8NDx1A01317@candle.pha.pa.us
Whole thread Raw
In response to restore time: sort_mem vs. checkpoing_segments  (Vivek Khera <khera@kcilink.com>)
Responses Re: restore time: sort_mem vs. checkpoing_segments  (Vivek Khera <khera@kcilink.com>)
Re: restore time: sort_mem vs. checkpoing_segments  (Dennis Bjorklund <db@zigo.dhs.org>)
List pgsql-performance
Vivek Khera wrote:
> And the winner is... checkpoint_segments.
>
> Restore of a significanly big database (~19.8GB restored) shows nearly
> no time difference depending on sort_mem when checkpoint_segments is
> large.  There are quite a number of tables and indexes.  The restore
> was done from a pg_dump -Fc dump of one database.
>
> All tests with 16KB page size, 30k shared buffers, sort_mem=8192, PG
> 7.4b2 on FreeBSD 4.8.
>
> 3 checkpoint_segments restore time: 14983 seconds
> 50 checkpoint_segments restore time: 11537 seconds
> 50 checkpoint_segments, sort_mem 131702 restore time: 11262 seconds

With the new warning about too-frequent checkpoints, people have actual
feedback to encourage them to increase checkpoint_segments.  One issue
is that it is likely to recommend increasing checkpoint_segments during
restore, even if there is no value to it being large during normal
server operation.  Should that be decumented?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-performance by date:

Previous
From: Vivek Khera
Date:
Subject: Re: restore time: sort_mem vs. checkpoing_segments
Next
From: Vivek Khera
Date:
Subject: Re: restore time: sort_mem vs. checkpoing_segments