Re: Smaller data types use same disk space - Mailing list pgsql-general

From Mike Christensen
Subject Re: Smaller data types use same disk space
Date
Msg-id CABs1bs2g4YjAc69Ns-AHMefB=dh8t9=FRcWvKB+g8R0GC0qANw@mail.gmail.com
Whole thread Raw
In response to Re: Smaller data types use same disk space  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Smaller data types use same disk space  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-general
On Wed, Jul 25, 2012 at 4:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Mike Christensen <mike@kitchenpc.com> writes:
>> On Wed, Jul 25, 2012 at 1:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yeah, this has been discussed multiple times.  The sticking point is
>>> the extra infrastructure needed to have a physical column numbering
>>> different from the user-visible numbering, and the 100% certainty of
>>> introducing a lot of bugs due to bits of code using one type of column
>>> number where they should have used the other.  We'll probably get it
>>> done someday, but don't hold your breath ...
>
>> Has there been any discussion of providing the ability to re-order
>> table columns through an ALTER TABLE command?
>
> It's more or less the same discussion.  To do either one you need to
> decouple the internal column order from what the user sees.  I do not
> think we'd bother with building the infrastructure involved if the
> only application were squeezing out alignment padding; it's really
> the (constant) requests for some kind of "ALTER TABLE REORDER COLUMNS"
> feature that make it worth thinking about.

I don't really think you'd need to decouple the internal column order
from what the user sees.  A REORDER COLUMNS command should re-build
the table with the columns in the specified order.  Internally, it
should be no different from making a new table, copying all the data
over, then deleting the old table.  If there's any optimizations that
can be done (such as making this faster on large tables), those could
be done in future versions.  I'd just like to changing column order
easier without remaking the table or renaming columns and changing
their data types (as suggested by Marc)

Mike

pgsql-general by date:

Previous
From: "Abraham, Danny"
Date:
Subject: FATAL : could not read directory base": Invalid argument
Next
From: leo xu
Date:
Subject: Re: how to calculate or know seq_scan scan how many blocks every time