Tom Lane wrote:
I said:
Sorry, you used up your chance at claiming that t_hoff is dispensable.
If we apply your already-submitted patch, it isn't.
Wait, I take that back. t_hoff is important to distinguish how much
bitmap padding there is on a particular tuple --- but that's really
Neil Conway wrote:
On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" [EMAIL PROTECTED] wrote:
-Original Message-
From: Manfred Koizar
If there is interest in reducing on-disk tuple header size and I have
not missed any strong arguments against dropping t_natts, I'll
- Original Message -
From: "Hiroshi Inoue" [EMAIL PROTECTED]
To: "Neil Conway" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, May 06, 2002 9:08 PM
Subject: Re: [HACKERS] Number of attributes in HeapTupleHeader
Neil Conway wrote:
On Mon, 6 May
Rod Taylor wrote:
I think the real trick is keeping track of the difference between:
begin;
ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
commit;
and
begin;
ALTER TABLE tab ADD COLUMN col1;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
The first should populate the
On Sun, 05 May 2002 23:48:31 +0200
Manfred Koizar [EMAIL PROTECTED] wrote:
Two years ago there have been thoughts about ADD COLUMN and whether it
should touch all tuples or just change the metadata. Could someone
tell me, what eventually came out of this discussion and where I find
the
On Sun, 5 May 2002 18:07:27 -0400, Neil Conway
[EMAIL PROTECTED] wrote:
See AlterTableAddColumn() in commands/tablecmds.c
Thanks. Sounds obvious. Should have looked before asking...
This doesn't look too promising:
* Implementation restrictions: because we don't touch the table rows,
Manfred Koizar [EMAIL PROTECTED] writes:
Currently there's an int16 t_natts in HeapTupleHeaderData. This
number is stored on disk for every single tuple. Assuming that the
number of attributes is constant for all tuples of one relation we
have a lot of redundancy here.
... but that's a
-Original Message-
From: Manfred Koizar
If there is interest in reducing on-disk tuple header size and I have
not missed any strong arguments against dropping t_natts, I'll
investigate further. Comments?
If a dbms is proper, it prepares a mechanism from the first
to handle ADD
On Mon, 6 May 2002 08:44:27 +0900
Hiroshi Inoue [EMAIL PROTECTED] wrote:
-Original Message-
From: Manfred Koizar
If there is interest in reducing on-disk tuple header size and I have
not missed any strong arguments against dropping t_natts, I'll
investigate further.
IMHO, the current ADD COLUMN mechanism is a hack. Besides requiring
redundant on-disk data (t_natts), it isn't SQL compliant (because
default values or NOT NULL can't be specified), and depends on
a low-level kludge (that the storage system will return NULL for
any attnums the # of the
I said:
Sorry, you used up your chance at claiming that t_hoff is dispensable.
If we apply your already-submitted patch, it isn't.
Wait, I take that back. t_hoff is important to distinguish how much
bitmap padding there is on a particular tuple --- but that's really
only interesting as long
11 matches
Mail list logo
