On Wed, Feb 07, 2007 at 09:38:30AM -0600, Dan Falconer wrote:
> One more quick note: over the night, we had a vacuum analyze run on the
> whole
> database (it's cronned to run weekly). In the output of the vacuum (it was
> set to verbose), it looks like our main inventory table had 7 indexes, each
> of which had 12.7M index row versions (along with 12.7 row versions from the
> table itself) removed. This would probably affect Slony *somehow*... but I'm
> not sure if it would directly contribute to the problem at hand.
Running a vacuum analyse on a weeky basis not linked to replacing all
those rows will indeed make performace crawl. I actually suggest you
look at autovacuum, but if you don't like that option, I think you
need to look at which tables are getting changed a lot, and vacuum
them _way_ more often. In particular, given the number of rows you
change in each transaction, why not schedule a vacuum of the relevant
tables between each COMMIT; BEGIN in your inventory procedure?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
If they don't do anything, we don't need their acronym.
--Josh Hamilton, on the US FEMA
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
