Re: Vaccuming dead rows on busy databases

From: Matthew O'Connor <matthew(at)zeut(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Vaccuming dead rows on busy databases
Date: 2006-12-18 19:40:34
Message-ID: 4586EEB2.2070909@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> I'd like to see something like VACUUM FULL WAIT. :)
>
> Sounds like a deadlock waiting to happen :-(
>
> AFAIK the general practice is to just accept the fact that vacuum can't
> remove recently-dead tuples. You should look into whether you can't
> shorten your transactions --- very-long-running transactions create
> other performance issues besides vacuum not removing stuff.

It seems to me that the most common support problem I keep seeing on the
mailing lists is VACUUM not working well because of long running
transactions. If I understand it correctly, people have talked about
reducing the problem by tracking xmin (or something, sorry if I'm
getting this wrong) on a per table basis rather and per cluster. Now
I'm sure this is not simple and I know I don't have the skills to do it,
but I think it would resolve (or at least significantly mitigate) what I
perceive as one of the biggest usage problems with PostgreSQL.

Comments?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matt Miller 2006-12-18 19:44:29 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE (was: [GENERAL] pgcluster-1.7.0rc1-patch)
Previous Message Tom Lane 2006-12-18 18:54:15 Re: Vaccuming dead rows on busy databases