> > I'll try tuning things if you can get the data to me, or give me > > access to the database. It's not always indexes. > Sometimes it's more > > along the lines of queries or vacuum. > > While setting up access to my data, I copied my bacula > database to a new database and had quite an unexpected > result. The query runs fast enough under the new database > while still running slowly on the old one.
This sounds like either table or index bloat. Typical reasons for tihs are not doing vacuum (which obviously isn't your problem), or having too few FSM pages. This can also be caused by not running vacuum earlier, but doing it now - if you got far enough away from the good path you'll need a VACUUM FULL to recover. You'll want to run VACUUM VERBOSE (database wide) to get a hint if this might be the issue. Or do you get significantly different plans from EXPLAIN? Could be a missing ANALYZE? > I am running pg_autovacuum (and I ran one by hand recently to > see if that would help) so I'm surprised that re-creating the > database would make this kind of difference. In general for a system like Bacula, I'd advise against using pg_autovacuum. There's always the risk that it'll kick in in the middle of a Bacula job. Since you almost certainly have a time when there are no jobs being processed in the database (I use th etime right after the catalog backup), you should just run a manual database-wide VACUUM ANALYZE then. //Magnus ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
