Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-10-18 Thread Larry Rosenman
Jim C. Nasby wrote: > On Sun, Oct 15, 2006 at 04:52:12PM +0200, Tobias Brox wrote: >> Are there any logs that can help me, and eventually, are there any >> ready-made scripts for checking when autovacuum is running, and >> eventually for how long it keeps its transactions? I'll probably >> write u

Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-10-18 Thread Jim C. Nasby
On Sun, Oct 15, 2006 at 04:52:12PM +0200, Tobias Brox wrote: > Are there any logs that can help me, and eventually, are there any > ready-made scripts for checking when autovacuum is running, and > eventually for how long it keeps its transactions? I'll probably write > up something myself if not.

Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-10-15 Thread Tobias Brox
[Matthew T. O'Connor - Sun at 10:42:34AM -0400] > Yeah, I think if the delay settings are too high it can cause problems, > that's part of the reason we have yet to turn these on be default since > we won't have enough data to suggest good values. Can you tell us what > settings you finally set

Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-10-15 Thread Matthew T. O'Connor
Tobias Brox wrote: [Matthew T. O'Connor - Wed at 02:33:10PM -0400] In addition autovacuum respects the work of manual or cron based vacuums, so if you issue a vacuum right after a daily batch insert / update, autovacuum won't repeat the work of that manual vacuum. I was experimenting

Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-10-15 Thread Tobias Brox
[Matthew T. O'Connor - Wed at 02:33:10PM -0400] > In addition autovacuum respects the work of manual or cron based > vacuums, so if you issue a vacuum right after a daily batch insert / > update, autovacuum won't repeat the work of that manual vacuum. I was experimenting a bit with autovacuum no

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-28 Thread Edoardo Ceccarelli
True, but autovacuum could check load -before- and -during- it's execution and it could adjust himself automatically to perform more or less aggressively depending on the difference between those two values. Maybe with a parameter like: maximum-autovacuum-load=0.2 that would mean: "n

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Bill Moran
In response to Edoardo Ceccarelli <[EMAIL PROTECTED]>: > Rod Taylor wrote: > > On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote: > > > >> I have read that autovacuum cannot check to see pg load before > >> launching > >> vacuum but is there any patch about it? that would sort out th

Re: [ADMIN] [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Matthew T. O'Connor
Csaba Nagy wrote: On Wed, 2006-09-27 at 18:08, Edoardo Ceccarelli wrote: How can I configure the vacuum to run after the daily batch insert/update? Check out this: http://www.postgresql.org/docs/8.1/static/catalog-pg-autovacuum.html By inserting the right row you can disable autovacuu

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Rod Taylor
On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote: > > I have read that autovacuum cannot check to see pg load before > launching > vacuum but is there any patch about it? that would sort out the > problem > in a good and simple way. In some cases the solution to high load is to vacu

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Tobias Brox
[Edoardo Ceccarelli - Wed at 06:49:23PM +0200] > ...another thing is, how could autovacuum check for machine load, this > is something I cannot imagine right now... One solution I made for our application, is to check the pg_stats_activity view. It requires some config to get the stats available

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Edoardo Ceccarelli
Rod Taylor wrote: On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote: I have read that autovacuum cannot check to see pg load before launching vacuum but is there any patch about it? that would sort out the problem in a good and simple way. In some cases the

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Edoardo Ceccarelli
Bill Moran wrote: In response to Edoardo Ceccarelli <[EMAIL PROTECTED]>: I have read that autovacuum cannot check to see pg load before launching vacuum but is there any patch about it? that would sort out the problem in a good and simple way. Otherwise, which kind of set of par

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Bill Moran
In response to Edoardo Ceccarelli <[EMAIL PROTECTED]>: > Hello, > > we are running a 7.3 postgres db with only a big table (avg > 500.000records) and 7 indexes for a search engine. > we have 2 of this databases and we can switch from one to another. > Last week we decided to give a try to 8.1 on

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Csaba Nagy
On Wed, 2006-09-27 at 18:08, Edoardo Ceccarelli wrote: > How can I configure the vacuum to run after the daily batch insert/update? Check out this: http://www.postgresql.org/docs/8.1/static/catalog-pg-autovacuum.html By inserting the right row you can disable autovacuum to vacuum your big tables,

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Tobias Brox
[Edoardo Ceccarelli - Wed at 06:08:30PM +0200] > We also activated the autovacuum feature to give it a try and that's > were our problems started. (...) > How can I configure the vacuum to run after the daily batch insert/update? I think you shouldn't use autovacuum in your case. We haven't dare

Re: [PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Alan Hodgson
On Wednesday 27 September 2006 09:08, Edoardo Ceccarelli <[EMAIL PROTECTED]> wrote: > > How can I configure the vacuum to run after the daily batch > insert/update? > If you really only want it to run then, you should disable autovacuum and continue to run the vacuum manually. You might also in

[PERFORM] autovacuum on a -mostly- r/o table

2006-09-27 Thread Edoardo Ceccarelli
Hello, we are running a 7.3 postgres db with only a big table (avg 500.000records) and 7 indexes for a search engine. we have 2 of this databases and we can switch from one to another. Last week we decided to give a try to 8.1 on one of them and everything went fine, db is faster (about 2 or 3