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 an
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 r
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 u
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 aut
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
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 r
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 pg_sta
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
"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_s
>> 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
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 collide
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 t
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 thi
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 exa
14 matches
Mail list logo
