On Nov 10, 2005, at 3:43 PM, Matthew T. O'Connor wrote:
Yes exactly, and if you find that pg_autovacuum is never or not
often enough firing off vacuum comands, then you will need to play
with the threshold settings. The default thresholds for
pg_autovacuum are too conservative for most
Vivek Khera wrote:
Another issue with autovacuum (haven't investigated the 8.1 version
yet) is that you can't make different threshhold settings for
different tables. For example, I have some tables that are a handful
of rows but are updated bazillions of times per day, and other tables
with
This is also true in my situation, where I have some medium sized
tables, which have a always just a handful of rows heavily updated. The
amount of updates is not too big related to the size of the table, but
the repeated update of the same row will cause problems before
autovacuum will kick in,
[snip]
With the release of 8.1 and it's integrated version of autovacuum, you
can now set per table settings for for vauum and analyze thresholds,
vacuum cost delay, and table enable / disable. This addresses what was
probably the largest deficiency with the old contrib version.
Cool ! I
OK, I've found it:
http://www.postgresql.org/docs/8.1/interactive/catalog-pg-autovacuum.html
One more incentive to upgrade as quickly as possible.
Cheers,
Csaba.
On Fri, 2005-11-11 at 17:40, Csaba Nagy wrote:
[snip]
With the release of 8.1 and it's integrated version of autovacuum, you
Hi Matthew,
Would rebooting the server interfere with the work of pg_autovacuum? I
imagine that pg_autovacuum would loose the information that it gathered
prior to the reboot.
Would not pg_autovacuum need to gather data about the database again before
it can judge if it should analyze/vacuum a
Carlos Oliva [EMAIL PROTECTED] writes:
Would rebooting the server interfere with the work of pg_autovacuum? I
imagine that pg_autovacuum would loose the information that it gathered
prior to the reboot.
The only long-term state used by autovacuum is the contents of the
statistics views, which
Hi Forum,
Should autovacuum reclaim most of the free space of a
database? We are trying to configure our database and running
pg_autovacuum to streamline our database. We have increased the
max_fsm_pages to a value larger than the total pages needed (see the output
from a full vacuum
Couple of thing here:
1) Just because autovacuum is running, doesn't mean that it has actually
tried to vacuum a table. 5 minutes is the time that it sleeps in between
investigating activity to see if a vacuum is needed. If you want to see
if pg_autovacuum has actually tried to do anything you
Thank you for your response Matthew. Currently I run pg_autovacuum with the
following scripts.
su -l postgres -c pg_autovacuum -D -U postgres /dev/null 21
Do you suggest that I could change it to something like the following:
su -l postgres -c pg_autovacuum -d2 -D -U postgres /tmp/vacuum.log
Carlos Oliva wrote:
Thank you for your response Matthew. Currently I run pg_autovacuum with the
following scripts.
su -l postgres -c pg_autovacuum -D -U postgres /dev/null 21
Do you suggest that I could change it to something like the following:
su -l postgres -c pg_autovacuum -d2 -D -U
11 matches
Mail list logo
