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!
--------------------------------------------------------------

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match