On Mon, May 22, 2006 at 06:43:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Wed, May 17, 2006 at 10:29:14PM -0400, Tom Lane wrote:
> >> The reason the default is currently 10 is just conservatism: it was
> >> already an order of magnitude better than what it replaced (a *single*
> >> representative value) and I didn't feel I had the evidence to justify
> >> higher values. It's become clear that the default ought to be higher,
> >> but I've still got no good fix on a more reasonable default. 100 might
> >> be too much, or then again maybe not.
>
> > Is the only downside to a large value planning speed? It seems it would
> > be hard to bloat that too much, except in cases where people are
> > striving for millisecond response times, and those folks had better know
> > enough about tuning to be able to adjust the stats target...
>
> It would be nice to have some *evidence*, not unsupported handwaving.
If someone has an idea on how to actually get that evidence, I'm all
ears. In the meantime, the number of people that run into problems with
the default of 10 provides pretty good evidence that that number is far
too low, so it would be better to take a guess at a better number and
miss whatever would be optimal than continue on with something that's
pretty clearly a problem.
Of course this applies to other GUC's as well; the autovacuum settings
come to mind, now that 8.2 does a better job of finding a more realistic
value for shared_buffers.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461