Re: auto truncate/vacuum full

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, JC Praud <brutaltruth42(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: auto truncate/vacuum full
Date: 2009-10-27 20:40:25
Message-ID: alpine.GSO.2.01.0910271636491.3435@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 27 Oct 2009, Tom Lane wrote:

> The issue I can see is that we might never be able to complete any
> truncation if there's a lot of potentially removable pages and a pretty
> steady flow of conflicting lock attempts. But that would result in
> failure to remove bloat, not stoppage of conflicting queries.

That's exactly it. It's possible to get into a situation where it becomes
increasingly difficult to even catch up bloat once you get behind by a
certain amount. All it takes is one giant deletion and you can get stuck
here until there's a window to take the database down altogether, and you
could end up down for hours waiting for that to execute.

> It might be worth allowing autovacuum to execute the truncation every
> few hundred pages, so as to ensure that progress can be made even if it
> never gets a very long uninterrupted lock on the table.

That was the sort of thing I was alluding to, moving in that direction
would seem much more valuable than trying to optimize the existing
approach better.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-10-27 20:47:53 Re: auto truncate/vacuum full
Previous Message Tom Lane 2009-10-27 20:33:29 Re: auto truncate/vacuum full