Re: Smaller data types use same disk space

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Mike Christensen <mike(at)kitchenpc(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "McGehee, Robert" <Robert(dot)McGehee(at)geodecapital(dot)com>, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Smaller data types use same disk space
Date: 2012-07-26 16:12:44
Message-ID: CAHyXU0x34oFEGHLwb67oouUusMhvo-YepJhcrV4eJxMOKS=dmw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen <mike(at)kitchenpc(dot)com> wrote:
> 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)

That's a controversial point: doing it that way makes reordering of
large tables highly impractical. A column map turns that into a
catalog update which can be done at any time. I would argue that you
can have it both ways: implement the map and have table rebuilding
operations (like TRUNCATE and CLUSTER) opportunistically do the
physical swap.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-07-26 16:19:36 Re: Smaller data types use same disk space
Previous Message leo xu 2012-07-26 16:05:00 Re: how to calculate or know seq_scan scan how many blocks every time