Re: [Open Item] Re: [HACKERS] Autovacuum on by default?

2006-08-27 Thread Tom Lane
Jim C. Nasby [EMAIL PROTECTED] writes:
 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.

That's a mistaken argument, because the reason stats_command_string
is now on is that it was reimplemented in a way that has basically
nothing to do with the stats subsystem ...

regards, tom lane

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


Re: [Open Item] Re: [HACKERS] Autovacuum on by default?

2006-08-26 Thread Peter Eisentraut
Jim C. Nasby wrote:
 I thought we had agreed it would be a good idea to turn autovac_delay
 on?

We had not, because there was no experience available about where to put 
the default numbers.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


[Open Item] Re: [HACKERS] Autovacuum on by default?

2006-08-25 Thread Alvaro Herrera
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.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [Open Item] Re: [HACKERS] Autovacuum on by default?

2006-08-25 Thread Jim C. Nasby
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.comwork: 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