Re: [Open Item] Re: [HACKERS] Autovacuum on by default?
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?
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?
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?
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