Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 9567E9FB292
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Wed,  7 Mar 2007 00:35:05 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 10428-07 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Wed,  7 Mar 2007 00:35:00 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 76ADD9FB1DD
	for <pgsql-hackers@postgresql.org>;
	Wed,  7 Mar 2007 00:35:00 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l274YvBW014521;
	Tue, 6 Mar 2007 23:34:57 -0500 (EST)
To: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: Aggressive freezing in lazy-vacuum 
In-reply-to: <20070307110352.5E09.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> 
References: <20070306181253.64A9.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
	<4399.1173193354@sss.pgh.pa.us>
	<20070307110352.5E09.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
Comments: In-reply-to ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
	message dated "Wed, 07 Mar 2007 11:18:20 +0900"
Date: Tue, 06 Mar 2007 23:34:57 -0500
Message-ID: <14520.1173242097@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.06 tagged_above=0 required=5 tests=AWL, BAYES_50,
	SPF_HELO_PASS, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200703/455
X-Sequence-Number: 99939

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I said nothing about expired tuples.  The point of not freezing is to
>> preserve information about the insertion time of live tuples.

> I don't know what good it will do -- for debugging?

Exactly.  As an example, I've been chasing offline a report from Merlin
Moncure about duplicate entries in a unique index; I still don't know
what exactly is going on there, but the availability of knowledge about
which transactions inserted which entries has been really helpful.  If
we had a system designed to freeze tuples as soon as possible, that info
would have been gone forever pretty soon after the problem happened.

I don't say that this behavior can never be acceptable, but you need
much more than a marginal performance improvement to convince me that
it's worth the loss of forensic information.

			regards, tom lane