Re: reclaiming diskspace bloat w/near-zero downtime

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: reclaiming diskspace bloat w/near-zero downtime
Date: 2004-12-03 16:24:48
Message-ID: 200412030924.48665.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday December 3 2004 9:09, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > [SIDEBAR: Vacuum + fsm is not working as
> > I expected; it is clearly not reclaiming space resulting from the
> > UPDATEs. If I UPDATE 10000 rows and then run vacuum, I was
> > expecting/hoping that a subsequent UPDATE of 9000 rows would largely
> > reuse the space reclaimed from the 10000-row UPDATE.]
>
> VACUUM can't reclaim rows until the last transaction that could
> potentially see those rows is gone. I'd venture that your above
> disappointment occurs because there is some other transaction staying
> open across the update/vacuum sequence.

That sounds very possible; these systems are under heavy load most all the
time. Anytime vacuum starts, there are almost certainly other transactions
in process. Wondering how to confirm/report this? I know how to grab a
list of backends and their current queries, but is there a query to grab a
snapshot of open transactions for before and after comparisons?

I assume upgrading to 7.4.6 would not help this particular issue if that's
what's going on?

Sounds like 24x7x365 operations on a single cluster is maybe too tall of an
order under these loads. Maybe time for slony & friends for maintenance
switchovers.

Ed

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Leonardo Mateo 2004-12-03 16:30:44 Older Windows versions
Previous Message Tom Lane 2004-12-03 16:23:21 Re: table inheritance and DB design