if we had a pg_vacuum table that had the last timestamp of a vacuum/analyze for each table and the stats looked like the default, why not just print a warning message out to the user?
---------- Original Message ----------- From: Tom Lane <[EMAIL PROTECTED]> To: Peter Eisentraut <[EMAIL PROTECTED]> Cc: "Mark Woodward" <[EMAIL PROTECTED]>, pgsql-hackers@postgresql.org Sent: Sun, 12 Feb 2006 11:18:03 -0500 Subject: Re: [HACKERS] Analyze and vacuum, they are sort of mandatory.... > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Yes, that is what autovacuum does. It detects changes in the database > > and runs analyze if failing to do so would cause PostgreSQL to behave > > badly. I don't know why it's not turned on by default. > > Conservatism. It may well be on by default in some future release, > but that's not happening in the first release where the code exists > at all. > > autovacuum isn't a 100% solution to the sort of problems Mark is > complaining about anyway: on a freshly-loaded table you could get bad > plans because autovacuum hadn't gotten to it yet. > > One thing we could consider doing is boosting up the default no-stats > assumption about the number of distinct values in a column, to the point > where the planner wouldn't try a hash aggregate unless it had actual > stats. However, I'm unsure what negative side-effects that might have. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq ------- End of Original Message ------- ---------------------------(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
