Re: Query runs 38 seconds for small database!
От | Jan de Visser |
---|---|
Тема | Re: Query runs 38 seconds for small database! |
Дата | |
Msg-id | 200605081519.39293.jdevisser@digitalfairway.com обсуждение исходный текст |
Ответ на | Re: Query runs 38 seconds for small database! ("Andrus" <eetasoft@online.ee>) |
Ответы |
Re: Query runs 38 seconds for small database!
|
Список | pgsql-performance |
On Monday 08 May 2006 14:10, Andrus wrote: > > The only reason for being so conservative that I'm aware of was that it > > was a best guess. Everyone I've talked to cuts the defaults down by at > > least a factor of 2, sometimes even more. > > Can we ask that Tom will change default values to 2 times smaller in 8.1.4 > ? > > > BTW, these parameters are already tweaked from what we started with in > > contrib/pg_autovacuum. It would allow a table to grow to 2x larger than > > it should be before vacuuming, as opposed to the 40% that the current > > settings allow. But even there, is there any real reason you want to > > have 40% bloat? To make matters worse, those settings ensure that all > > but the smallest databases will suffer runaway bloat unless you bump up > > recprd> the FSM settings. > > I created empty table konto and loaded more that 219 records to it during > database creation. > So it seems that if table grows from zero to more than 219 times larger > then it was still not processed. That's because you need at least 500 rows for analyze and 100 for a vacuum, (autovacuum_vacuum_threshold = 1000, autovacuum_analyze_threshold = 500). > > Andrus. jan > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
В списке pgsql-performance по дате отправления: