Re: degenerate performance on one server of 3 - Mailing list pgsql-performance

From Erik Aronesty
Subject Re: degenerate performance on one server of 3
Date
Msg-id ccd588d90906031230i2aa2364fo429d25ae20a9fb86@mail.gmail.com
Whole thread Raw
In response to Re: degenerate performance on one server of 3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: degenerate performance on one server of 3
Re: degenerate performance on one server of 3
List pgsql-performance
I think, perhaps, autovac wasn't running on that machine.

Is there any way to check to see if it's running?

I have enabled all the options , and I know it's running on my other
servers because I see

LOG: autovacuum....  entries (a profusion of them)

I suspect, perhaps, that it's just not showing up in the log since my
8.2 BSD box came with different settings by default.

current settings:

autovacuum = on
stats_start_collector = on              # needed for block or row stats
stats_row_level = on
log_min_error_statement = error
log_min_messages = notice
log_destination = 'syslog'
client_min_messages = notice

....should be enought to get it going and for me to see it right?  not
sure which setting controls logging of autovac, nor am i sure of a way
to *ask* the server if autovac is running.

On Mon, Jun 1, 2009 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Erik Aronesty <erik@q32.com> writes:
>> but why wasn't autovac enough to reclaim at least *most* of the space?
>
> Autovac isn't meant to reclaim major amounts of bloat; it's more in the
> line of trying to prevent it from happening in the first place.  To
> reclaim bloat it would have to execute VACUUM FULL, or some other
> operation that requires exclusive table lock, which doesn't seem like
> a good idea for an automatic background operation.
>
>                        regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Scalability in postgres
Next
From: Scott Carey
Date:
Subject: Re: Scalability in postgres