On Fri, Aug 25, 2006 at 12:16:33PM -0400, Alvaro Herrera wrote: > Tom Lane wrote: > > "Matthew T. O'Connor" <email@example.com> writes: > > > Peter Eisentraut wrote: > > >> - Leave base thresholds alone (pending further analysis that might > > >> remove them > > >> altogether?) > > > > > While there is talk of removing this all together, I think it was also > > > agreed that as long as these values are there, they should be reduced. > > > I think the defaults in 8.1 are 1000/500, I think 200/100 was suggested. > > > > ISTM that if we don't want to remove the thresholds immediately, > > we should make them default to zero for a release or two and see how > > well it works. > > > > At the moment I can't find the thread that discussed removing them, > > but IIRC there were some good arguments why the thresholds should always > > be zero. > > I can't find it either, but I think the bug reported here is related: > > http://archives.postgresql.org/pgsql-general/2006-06/thrd2.php#00951 > > On the other hand, I don't think we completely resolved this, so I > proposed this be added to the "Open Items" list.
Yeah, I think there's reasons we can't go to zero. 200/100 or even 20/10 would probably be a good compromise. I agree that droping to 0.08 might be a bit much, but it would be good if we started recommending that value to folks to see how well it works. I thought we had agreed it would be a good idea to turn autovac_delay on? I know there was question as to what a good value would be, but 5-10ms seems pretty reasonable. I think it'd also be good to up the cost threshold and the dirty_page cost, though I don't have much data to back that up (I did testing at one customer on a drive array and found 300 and 30 were good values). If we've got command stats turned on by default now, I'll have a hard time buying performance as any reason to turn the others off. I think we should turn them all on and let those who are trying to eek the last few percent of performance out of a system turn them off. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(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