On Thu, May 21, 2009 at 4:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> Schemes like this have been discussed before but I don't think we
>> considered applying the limitation that only the "first" default value
>> would be covered. We always wanted to be able to handle new defaults
>> or making a non-null column nullable later.
> Yeah ... I don't see exactly what it would buy to restrict it to just
> the first such value.
Well it wouldn't buy you steady-state space savings or performance improvements.
What it would buy you is a much narrowed set of circumstances where
ALTER TABLE ADD COLUMN goes from a fast O(1) catalog change to a
complete table rewrite. The use cases covered such as "boolean DEFAULT
false" or "integer DEFAULT 0" are extremely common.
I think users today often avoid the full table rewrite either make
their application treat null as implicitly the default value or do a
piecemeal rewrite using updates.
I think Robert Haas is right that we could handle any stable
expression by evaluating the expression once and storing only the
final resulting value as a constant. That would avoid the problems
with dependencies and later changes to functions.
Another gotcha is that the default value might be very large.... It
can't be very common but I suppose we would have to take some care
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-05-21 16:26:08|
|Subject: Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx? |
|Previous:||From: Robert Haas||Date: 2009-05-21 15:38:22|
|Subject: Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?|