Re: restore time: sort_mem vs. checkpoing_segments
От | Robert Treat |
---|---|
Тема | Re: restore time: sort_mem vs. checkpoing_segments |
Дата | |
Msg-id | 1063829746.25694.91.camel@camel обсуждение исходный текст |
Ответ на | 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 |
On Mon, 2003-09-15 at 15:15, 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. hmm... i wonder what would happen if you pushed your sort_mem higher... on some of our development boxes and upgrade scripts, i push the sort_mem to 102400 and sometimes even higher depending on the box. this really speeds up my restores quit a bit (and is generally safe as i make sure there isn't any other activity going on at the time) another thing i like to do is turn of fsync, as if the system crashes in the middle of reload i'm pretty sure i'd be starting all over anyway... Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
В списке pgsql-performance по дате отправления: