Pavan Deolasee wrote:
On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
The
policy of this project is that we only put nontrivial bug fixes into
back branches, and I don't think this item qualifies ...
Got it. I will submit a patch for HEAD.
Thanks,
As I mentio
Please do --- I have a lot of other stuff on my plate.
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
I have
I have a table with about 15 million rows which is constantly having
tuples added to the head and deleted in blocks from the tail to maintain
the size. The dead tuple count in pg_stat_user_tables tracks the deleted
rows fairly accurately until an auto-ANALYZE is done in the background
at which
I am experiencing a strange problem where autovacuum appears to be
vacuuming 1 table in preference to another even through they have very
similar usage patterns.
For this test case I have 2 tables, 'transactions' and 'lineitems', and
the ratio of writes is approx 1:3. I am filling these tables
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
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
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
>> 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
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
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
11 matches
Mail list logo
