Re: effective SELECT from child tables - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: effective SELECT from child tables
Date
Msg-id 1128398775.6543.165.camel@home
Whole thread Raw
In response to Re: effective SELECT from child tables  (Rod Taylor <pg@rbt.ca>)
List pgsql-hackers
On Mon, 2005-10-03 at 23:51 -0400, Rod Taylor wrote:
> On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
> > Hannu Krosing <hannu@skype.net> writes:
> > 
> > > On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
> > > > 
> > > > Here's another interesting case to think about:
> > > > 
> > > >     ALTER TABLE ADD foo integer DEFAULT 1
> > > >     ...
> > > >     ALTER TABLE ALTER foo SET DEFAULT 2
> > > >
> > > > You'll have to pay the table-traversal cost on one step or the other.
> > > 
> > > The second, ALTER ... SET DEFAULT, would only set default for newly
> > > inserted columns, not the ones which are missing due to tuples being
> > > created before the column existed.
> > 
> > Hm. So you're saying there are only ever exactly two types of defaults. The
> > "initial" default that applies to all tuples that were created before the
> > column was added. And the "current" default that only ever applies to newly
> > created tuples.
> > 
> > That does seem to cleanly close this hole.
> 
> I don't think so.

Ignore me. The thread seems to be about allowing fast addition of
columns, not decreasing storage space.

For some reason I was thinking of a bitmap like the NULL bitmap for
compressing out all default values.


-- 



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: effective SELECT from child tables
Next
From: Greg Stark
Date:
Subject: Re: effective SELECT from child tables