To: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: VACUUMs and WAL
In-Reply-To: <1225183785.3971.114.camel@ebony.2ndQuadrant> (Simon Riggs's
	message of "Tue\, 28 Oct 2008 08\:49\:45 +0000")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <1225183785.3971.114.camel@ebony.2ndQuadrant>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Tue, 28 Oct 2008 10:59:51 +0000
Message-ID: <87bpx5c7dk.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Simon Riggs <simon@2ndQuadrant.com> writes:

> I don't see a reason why we would issue 2 WAL records per block for a
> VACUUM, nor why we would prune and remove in two steps, dirtying the
> block each time. Seems like we could write approximately half the amount
> of data that we do.
>
> Surely we can come up with a better plan than that one?

This sounds like the same issue Pavan identified and proposed solving by
rotating the three passes so that we do step 3 at the beginning of the next
vacuum run, so it can be done in the same pass as step 1.

To do that he proposed we do:

1. scan heap doing two things: a) remove any marked tuples if they were marked
   by a previous vacuum which committed and b) prune and mark any tuples we
   find are deletable for a future vacuum to remove.

2. scan indexes and remove the tuples we marked in 1b.

The main blocking issue IIRC was:

How to mark the tuples in a way which is safe if vacuum aborts. He suggested
putting a vacuum xid in pg_class. Other suggestions were to mark the pages in
the page header (which I thought made the most sense) or to put the xid in the
line pointer (since nothing else needs to go there, the tuples are already
cleaned).

There might also have been a question of how to deal with the statistics.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!