From: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx? |
Date: | 2009-05-21 18:07:07 |
Message-ID: | 5030A48F-B751-44B3-A115-3FC466067713@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--
Greg
On 21 May 2009, at 12:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> On Thu, May 21, 2009 at 4:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
>
> No, you missed my point --- what's the value of having an
> implementation
> of this that only works for one column? If we do it, I'd envision it
> as an extra column in pg_attribute, and it would work for any
> column(s).
> There's nothing to be gained by restricting it.
>
Oh, I never meant to restrict it to one column.
It might be nice to have vacuum notice the minimum natts in the table
and trim the old unneeded ones. But I can't think of a very compelling
reason to. Perhaps to save memory used in tuplestores?
>> 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.
>
> Right, that's *necessary* to avoid changing semantics compared to
> the non-optimized behavior.
I'm coming at it from the other direction. I was assuming we could
only handle simple constants and am trying to see how wide we can
expand it. Doing all stable expressions would seem pretty convincingly
wide to me.
>> 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
>> around that.
>
> Yeah, that occurred to me too. We'd probably not be able to toast
> the pg_attribute column (depending on exactly how it's
> declared/represented) so we'd have to put a limit on the width of
> data value that we'd be willing to handle this way. Seems doable
> though.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Prentice | 2009-05-21 18:46:24 | Re: [PATCH] 8.5 plpgsql change for named notation: treat word following AS keyword as label v3 |
Previous Message | Tom Lane | 2009-05-21 17:52:59 | Re: [PATCH] 8.5 plpgsql change for named notation: treat word following AS keyword as label v2 |