Re: Thank you!

See the attached file for details
>From pgsql-general-owner(at)postgresql(dot)org Wed Aug 20 11:33:08 2003
X-Original-To: pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 6F246D1BAA3
for <pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Wed, 20 Aug 2003 11:31:31 -0300 (ADT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 69357-04
for <pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Wed, 20 Aug 2003 11:31:24 -0300 (ADT)
Received: from yertle.kcilink.com (yertle.kcilink.com [216.194.193.105])
by svr1.postgresql.org (Postfix) with ESMTP id AD521D1B8B5
for <pgsql-general(at)postgresql(dot)org>; Wed, 20 Aug 2003 11:31:20 -0300 (ADT)
Received: by yertle.kcilink.com (Postfix, from userid 100)
id 340E721790; Wed, 20 Aug 2003 10:31:25 -0400 (EDT)
From: Vivek Khera <khera(at)kcilink(dot)com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16195(dot)34365(dot)74942(dot)761844(at)yertle(dot)int(dot)kciLink(dot)com>
Date: Wed, 20 Aug 2003 10:31:25 -0400
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Buglist
In-Reply-To: <20030820132059(dot)GA5221(at)wolff(dot)to>
References: <1061292720(dot)1925(dot)79(dot)camel(at)localhost>
<x7brulu0fq(dot)fsf(at)yertle(dot)int(dot)kciLink(dot)com>
<200308192110(dot)09958(dot)shridhar_daithankar(at)nospam(dot)persistent(dot)co(dot)in>
<x73cfxtyky(dot)fsf(at)yertle(dot)int(dot)kciLink(dot)com>
<1061333621(dot)28374(dot)6(dot)camel(at)zeutrh9>
<16194(dot)54290(dot)800263(dot)142593(at)yertle(dot)int(dot)kciLink(dot)com>
<20030820132059(dot)GA5221(at)wolff(dot)to>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200308/1060
X-Sequence-Number: 47476

>>>>> "BW" == Bruno Wolff, <Bruno> writes:

>> to see it incremental. This would result in pretty much near zero
>> internal fragmentation, I think.

BW> Why do you care about about the details of the implementation (rather than
BW> the performance)? If it were faster to do it that way, that's how it would
BW> have been done in the first place. The cost of doing the above is almost
BW> certainly going to be an overall performance loser.

I care for the performance. And how are you so sure that it was
faster the way it is now? Are you sure it was not done this way
because of ease of implementation?

Seriously, how much slower can it be if the backend were to do the
checking for external references upon updating/deleting a row? The
cost would be distributed across time as opposed to concentrated at
once within a vacuum process. I am fairly certian it would reduce
disk bandwidth requirements since at least one necessary page will
already be in memory.