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?
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 |