To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Pavan Deolasee" <pavan.deolasee@gmail.com>,
	"Pgsql Hackers" <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] VACUUM Improvements - WIP Patch
In-Reply-To: <8741.1216049025@sss.pgh.pa.us> (Tom Lane's message of "Mon\,
	14 Jul 2008 11\:23\:45 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <2e78013d0806092232h6ca15ffejcbcd24e88401308f@mail.gmail.com>
	<21751.1215883933@sss.pgh.pa.us>
	<2e78013d0807132050j16cdc558s4dc3f889371a937d@mail.gmail.com>
	<8741.1216049025@sss.pgh.pa.us>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Mon, 14 Jul 2008 18:15:42 +0100
Message-ID: <87hcasmloh.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

>>> It strikes me that what you are trying to do here is compensate for
>>> a bad decision in the HOT patch, which was to have VACUUM's first
>>> pass prune/defrag a page even when we know we are going to have to
>>> come back to that page later.  What about trying to fix things so
>>> that if the page contains line pointers that need to be removed,
>>> the first pass doesn't dirty it at all, but leaves all the work
>>> to be done at the second visit?
>
>> I am not against this idea. Just that it still requires us double scan
>> of the main table and that's exactly what we are trying to avoid with
>> this patch.
>
> The part of the argument that I found convincing was trying to reduce
> the write traffic (especially WAL log output), not avoiding a second
> read.  And the fundamental point still remains: the work should be done
> in background, not foreground.

I like the idea of only having to do a single pass through the table though.
Couldn't Pavan's original plan still work and just not have other clients try
to remove dead line pointers? At least not unless they're also pruning the
page due to an insert or update anyways?

Fundamentally it does seem like we want to rotate vacuum's work-load. What
we're doing now is kind of backwards.

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