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
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
> "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
> "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
> "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
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
> "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
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
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
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
10 matches
Mail list logo