Stuart Brooks wrote:
Are you measuring index as well as table size? VACUUM FULL is no good
at compacting indexes.
I am measuring pg_total_relation_size which I believe includes indexes.
How does one go about compacting indexes if a VACUUM doesn't do the
trick? I see that a
Are you measuring index as well as table size? VACUUM FULL is no good
at compacting indexes.
I am measuring pg_total_relation_size which I believe includes indexes.
How does one go about compacting indexes if a VACUUM doesn't do the
trick? I see that a recommendation is to drop
ERROR: canceling autovacuum task
CONTEXT: automatic vacuum of table metadb.test.transactions
Are these happening regularly? They indicate that something is
happening on the table that collides with what autovacuum needs to do,
and autovacuum defers its task. For this to happen you need to
On Tue, Feb 26, 2008 at 3:11 PM, Stuart Brooks [EMAIL PROTECTED] wrote:
ERROR: canceling autovacuum task
CONTEXT: automatic vacuum of table metadb.test.transactions
Are these happening regularly? They indicate that something is
happening on the table that collides with what
ERROR: canceling autovacuum task
CONTEXT: automatic vacuum of table metadb.test.transactions
Are these happening regularly? They indicate that something is
happening on the table that collides with what autovacuum needs to do,
and autovacuum defers its task. For this to happen
Stuart Brooks [EMAIL PROTECTED] writes:
It'll take a few minutes but I'll try and get the information to you. A
summary
is:
Process 1:
- writing 50 rows/second, 1 row/transaction.
- every so often delete 100 rows
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every
Stuart Brooks wrote:
I am not using an ALTER table command but I am doing periodic ANALYZEs
to evaluate the table size. Could this be causing the problem? I notice
that stopping the ANALYZE calls appears to eliminate the canceled
autovacuum.
Why were you running ANALYZE on the first
It'll take a few minutes but I'll try and get the information to you. A summary
is:
Process 1:
- writing 50 rows/second, 1 row/transaction.
- every so often delete 100 rows
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second
You'll probably have to vacuum
What concerns me is that once the size has grown, even a VACUUM FULL
doesn't recover the space. Regular external VACUUMs keep the table at
around 10MB but if I use autovacuum and it grows to 40MB, a VACUUM FULL
will only get it down to 35MB. Is it possible that a canceled autovacuum
could
Stuart Brooks [EMAIL PROTECTED] writes:
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second
The result is that autovacuum appears to be canceled.
Yes, that will pretty much guarantee that an autovacuum is never able to
complete...
What concerns me is that once the
Stuart Brooks wrote:
It'll take a few minutes but I'll try and get the information to you. A
summary is:
Process 1:
- writing 50 rows/second, 1 row/transaction.
- every so often delete 100 rows
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second
The result is that
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second
The result is that autovacuum appears to be canceled.
Yes, that will pretty much guarantee that an autovacuum is never able to
complete...
That's what I figured. Since I won't be running ANALYZE
Stuart Brooks wrote:
ERROR: canceling autovacuum task
CONTEXT: automatic vacuum of table metadb.test.transactions
Are these happening regularly? They indicate that something is
happening on the table that collides with what autovacuum needs to do,
and autovacuum defers its task. For this
It appears (and I am open to correction) that autovacuum is not
operating correctly in 8.3.0. I have a vanilla installation where
autovacuum is enabled, and is running with all the default settings.
I have a table which is continually having rows added to it (~50/sec).
For the sake of this
14 matches
Mail list logo
