"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,
table of the database?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew T. O'Connor
Sent: Thursday, November 10, 2005 3:44 PM
To: Carlos Oliva
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Performance of autovacuum and full vacu
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
>
[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 !
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, as
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
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 pe
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 2>&1"&
Do you suggest that I could change it to something like the following:
su -l postgres -c "pg_autovacuum -d2 -D -U
@postgresql.org
Subject: Re: [GENERAL] Performance of autovacuum and full vacuum of database
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
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
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 bel
11 matches
Mail list logo
