Hiroshi Inoue wrote:
> Tom Lane wrote:
>
> > Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
> > I think he made a representational mistake by trying to change the
> > attnums of dropped columns to be negative values.
>
> Negative attnums had 2 advantages then. It had a big
> advantage that initdb isn't needed. Note that it was
> only a trial hack and there was no consensus on the way.
> It was very easy to change the implementation to use
> attisdropped. OTOH physical/logical attnums approach
> needed the change on pg_class, pg_attribute and so
> I've never had a chance to open the patch to public.
> It was also more sensitive about oversights of needed
> changes than the attisdropped flag approach.
>
> > That means that
> > a lot of low-level places *do* need to know about the dropped-column
> > convention, else they can't make any sense of tuple layouts.
>
> Why ? As you already mentioned, there were not that many places
> to be changed.
>
> Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system, and the advantages. For
implementation, I thought we could do most of the work by filtering what
the client saw, and let the server just worry about physical numbering,
except for 'SELECT *' expansion.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>From [EMAIL PROTECTED] Thu Feb 21 00:12:40 2002
Return-path: <[EMAIL PROTECTED]>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g1L6CeQ05723
for <[EMAIL PROTECTED]>; Thu, 21 Feb 2002 01:12:40 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id ADB57475A98; Thu, 21 Feb 2002 00:56:56 -0500 (EST)
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
by postgresql.org (Postfix) with ESMTP id 8C1C447594C
for <[EMAIL PROTECTED]>; Thu, 21 Feb 2002 00:51:42 -0500 (EST)
Received: (from pgman@localhost)
by candle.pha.pa.us (8.11.6/8.10.1) id g1L5piM03851
for [EMAIL PROTECTED]; Thu, 21 Feb 2002 00:51:44 -0500 (EST)
From: Bruce Momjian <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Subject: [HACKERS] Logical vs. Physical attribute numbering
To: PostgreSQL-development <[EMAIL PROTECTED]>
Date: Mon, 18 Feb 2002 11:07:47 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk
Sender: [EMAIL PROTECTED]
Status: OR
We had a discussion a few days ago about removing attribute padding from
disk storage structures to fit more information on the disk.
Now, I question whether it is worth the added complexity to do this, but
the idea of having different logical and physical numbering of columns
seems like it may solve several problems:
o Columns can be reordered to minimize padding
o We can move variable length columns to the end, improving
performance
o We can fix inheritance problems in ADD COLUMN
o We can implement fast DROP COLUMN by renumbering the column
out of visibility
Comments?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
