From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Vivek Khera <khera(at)kcilink(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: restore time: sort_mem vs. checkpoing_segments |
Date: | 2003-09-23 13:59:01 |
Message-ID: | 200309231359.h8NDx1A01317@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2003-09-23 14:27:55 | Re: restore time: sort_mem vs. checkpoing_segments |
Previous Message | Nick Fankhauser | 2003-09-22 20:42:27 | How to make n_distinct more accurate. |