Re: Column storage positions - Mailing list pgsql-hackers

From Phil Currier
Subject Re: Column storage positions
Date
Msg-id c58979e50702210625m677291e8x8836a0d1b9fb9de5@mail.gmail.com
Whole thread Raw
In response to Re: Column storage positions  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Column storage positions  (Bruce Momjian <bruce@momjian.us>)
Re: Column storage positions  ("Florian G. Pflug" <fgp@phlo.org>)
Re: Column storage positions  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
On 2/21/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> I'd expect the system being able to reoder the columns to the most
> efficient order possible (performance-wise and padding-saving-wise),
> automatically.  When you create a table, sort the columns to the most
> efficient order; ALTER TABLE ADD COLUMN just puts the new columns at the
> end of the tuple; and anything that requires a rewrite of the table
> (ALTER TABLE ... ALTER TYPE for example; would be cool to have CLUSTER
> do it as well; and do it on TRUNCATE also) again recomputes the most
> efficient order.

That's exactly what I'm proposing.  On table creation, the system
chooses an efficient column order for you.  The next time an ALTER
TABLE operation forces a rewrite, the system would recompute the
column storage order.  I hadn't thought of having CLUSTER also redo
the storage order, but that seems safe since it takes an exclusive
lock on the table.  I'm less sure about whether it's safe to do this
during a TRUNCATE.

phil


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: New feature request: FlashBack Query
Next
From: Markus Schiltknecht
Date:
Subject: Re: tsearch in core patch, for inclusion