Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-24 Thread Dennis Bjorklund
On Tue, 23 Sep 2003, Bruce Momjian wrote: > 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 valu

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-23 Thread Bruce Momjian
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

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-23 Thread Vivek Khera
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes: BM> restore, even if there is no value to it being large during normal BM> server operation. Should that be decumented? Yes, right alongside the recommendation to bump sort_mem, even though in my tests sort_mem made no significant differen

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-23 Thread Vivek Khera
> "RT" == Robert Treat <[EMAIL PROTECTED]> writes: RT> hmm... i wonder what would happen if you pushed your sort_mem higher... RT> on some of our development boxes and upgrade scripts, i push the RT> sort_mem to 102400 and sometimes even higher depending on the box. this RT> really speeds up m

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-17 Thread Vivek Khera
> "RT" == Robert Treat <[EMAIL PROTECTED]> writes: RT> hmm... i wonder what would happen if you pushed your sort_mem higher... RT> on some of our development boxes and upgrade scripts, i push the RT> sort_mem to 102400 and sometimes even higher depending on the box. this RT> really speeds up m

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-17 Thread Robert Treat
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. T

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-16 Thread Vivek Khera
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes: TL> I was just bugging Marc for some useful data, so I'll ask you too: TL> could you provide a trace of the pg_restore execution? log_statement TL> plus log_duration output would do it. I am curious to understand TL> exactly which steps in the r

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-15 Thread Tom Lane
Vivek Khera <[EMAIL PROTECTED]> writes: > 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 da

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-15 Thread Josh Berkus
Vivek, > 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

[PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-15 Thread Vivek Khera
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 databas