--
Greg
On 21 May 2009, at 12:26, Tom Lane <t...@sss.pgh.pa.us> wrote:
Greg Stark <st...@enterprisedb.com> writes:
On Thu, May 21, 2009 at 4:22 PM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
