Re: restore time: sort_mem vs. checkpoing_segments
От | Bruce Momjian |
---|---|
Тема | Re: restore time: sort_mem vs. checkpoing_segments |
Дата | |
Msg-id | 200309231359.h8NDx1A01317@candle.pha.pa.us обсуждение исходный текст |
Ответ на | restore time: sort_mem vs. checkpoing_segments (Vivek Khera <khera@kcilink.com>) |
Ответы |
Re: restore time: sort_mem vs. checkpoing_segments
Re: restore time: sort_mem vs. checkpoing_segments |
Список | 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 по дате отправления: