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  (Vivek Khera <khera@kcilink.com>)
Re: restore time: sort_mem vs. checkpoing_segments  (Vivek Khera <khera@kcilink.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Is there a reason _not_ to vacuum continuously?
Следующее
От: "Matt Clark"
Дата:
Сообщение: Re: Is there a reason _not_ to vacuum continuously?