On Fri, Aug 25, 2006 at 12:16:33PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Matthew T. O'Connor" <matthew@zeut.net> 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

Reply via email to