Re: really lazy vacuums?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: really lazy vacuums?
Date: 2011-03-15 05:02:05
Message-ID: AANLkTinraLZEtP_nb_V4UJUm6ErNP+FATTFu9BiyfZbS@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 14, 2011 at 8:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Mar 14, 2011 at 4:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Um, if there are *no* dead tuples then we don't look at the indexes
>>> anyway ...
>
>> But you do still have to scan the heap twice.
>
> Seems like that should be fixable ... is the second pass actually
> going to do anything?

Err, I'm wrong. There's no second pass if there are exactly zero
tuples to prune. So the possible problem case is when there are some
dead tuples, but not all that many compared to the size of the
indexes. In theory, you could be better off just reclaiming free
space, and waiting for dead tuples to accumulate before cleaning the
indexes. I'm not certain whether that target is wide enough to be
worth aiming at, but it seems plausible that at least in some
workloads the opportunistic index cleaning stuff would keep index
bloat under control, so the only reason to ever make a full scan of
the indexes during vacuuming would be to avoid leaking CTIDs.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message sanjay verma 2011-03-15 05:03:05 PostgreSQL 8.4 support on Windows 2008 R2
Previous Message Robert Haas 2011-03-15 03:13:13 Re: really lazy vacuums?