Skip site navigation (1) Skip section navigation (2)

Re: pg_autovacuum not having enough suction ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,Otto Blomqvist <o(dot)blomqvist(at)secomintl(dot)com>,"pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: pg_autovacuum not having enough suction ?
Date: 2005-03-25 23:18:13
Message-ID: 16180.1111792693@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> I'm not sure if autovacuum could be taught to do that --- it could
>> perhaps launch a vacuum as soon as it notices a large fraction of the
>> table got deleted, but do we really want to authorize it to launch
>> VACUUM FULL?

> One problem with VACUUM FULL would be autovacuum waiting for an
> exclusive lock on the table.  Anyway, it is documented now as a possible
> issue.

I don't care too much about autovacuum waiting awhile to get a lock.
I do care about other processes getting queued up behind it, though.

Perhaps it would be possible to alter the normal lock queuing semantics
for this case, so that autovacuum's request doesn't block later
arrivals, and it can only get the lock when no one is interested in the
table.  Of course, that might never happen, or by the time it does
there's no point in VACUUM FULL anymore :-(

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Bruce MomjianDate: 2005-03-25 23:21:24
Subject: Re: pg_autovacuum not having enough suction ?
Previous:From: Joshua D. DrakeDate: 2005-03-25 23:17:06
Subject: Re: pg_autovacuum not having enough suction ?

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-03-25 23:21:24
Subject: Re: pg_autovacuum not having enough suction ?
Previous:From: Joshua D. DrakeDate: 2005-03-25 23:17:06
Subject: Re: pg_autovacuum not having enough suction ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group