Message-ID: <492A584A.4050704@enterprisedb.com>
Date: Mon, 24 Nov 2008 09:31:22 +0200
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Jeff Davis <pgsql@j-davis.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Visibility map, partial vacuums
References: <4905AE17.7090305@enterprisedb.com>
	<491D376B.9000608@enterprisedb.com>
	<491D7F52.6070908@enterprisedb.com>
	<4925664C.3090605@enterprisedb.com>
	<26361.1227467112@sss.pgh.pa.us>
	<1227471538.7370.14.camel@jdavis-laptop>
	<27709.1227475122@sss.pgh.pa.us>
In-Reply-To: <27709.1227475122@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Tom Lane wrote:
> Reflecting on it though, maybe Heikki described the behavior too
> pessimistically anyway.  If a page contains no dead tuples, it should
> get its bits set on first visit anyhow, no?  So for the ordinary bulk
> load scenario where there are no failed insertions, the first vacuum
> pass should set all the bits ... at least, if enough time has passed
> for RecentXmin to be past the inserting transaction.

Right. I did say "... after a delete or update, it takes two vacuums 
until ..." in my mail.

> However, my comment above was too optimistic, because in an insert-only
> scenario autovac would in fact not trigger VACUUM at all, only ANALYZE.
> 
> So it seems like we do indeed want to rejigger autovac's rules a bit
> to account for the possibility of wanting to apply vacuum to get
> visibility bits set.

I'm not too excited about triggering an extra vacuum. As Matthew pointed 
out, the point of this patch is to reduce the number of vacuums 
required, not increase it. If you're not going to vacuum a table, you 
don't care if the bits in the visibility map are set or not.

We could set the PD_ALL_VISIBLE flag more aggressively, outside VACUUMs, 
if we want to make the seqscan optimization more effective. For example, 
a seqscan could set the flag too, if it sees that all the tuples were 
visible, and had the XMIN_COMMITTED and XMAX_INVALID hint bits set.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com