From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shane Dawalt <shane(dot)dawalt(at)wright(dot)edu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: full featured alter table? |
Date: | 2003-06-17 15:18:24 |
Message-ID: | 12914.1055863104@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Shane Dawalt <shane(dot)dawalt(at)wright(dot)edu> writes:
> I have been following this thread with great interesting and
> perplexity. I have yet to understand the reasoning behind this proposed
> addition.
The original takeoff point was the observation that you couldn't build
"ALTER COLUMN TYPE" out of the existing spare parts: you can make a new
column, load it with the old data, and drop the old column (with a
rename somewhere along the line) ... but this leaves you with the new
column at the end, so it's not a fully transparent substitution.
> Insofaras rearranging the internal table is concerned, I don't
> believe the pg people had that intent in mind at all. It may have been
> the intent of the original poster, but I think most everyone agrees that
> the back-end knows far better than us humans what is more optimal for
> table layout.
Indeed, but under the constraints of the SQL spec, the backend is not
free to change the visible column order for implementation reasons.
If we were to decouple logical and physical order as this thread is
suggesting, then the door *would* be open to perform that sort of
optimization.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Luc Lachance | 2003-06-17 15:18:34 | Re: order of nested loop |
Previous Message | Martijn van Oosterhout | 2003-06-17 15:15:34 | Re: Sort memory not being released |