From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Phil Currier <pcurrier(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Column storage positions |
Date: | 2007-02-21 14:55:52 |
Message-ID: | 200702211455.l1LEtq803457@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Phil Currier wrote:
> On 2/21/07, Alvaro Herrera <alvherre(at)commandprompt(dot)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.
Keep in mind we have a patch in process to reduce the varlena length and
reduce alignment requirements, so once that is in, reordering columns
will not be as important.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-02-21 14:59:12 | Re: Column storage positions |
Previous Message | Tom Lane | 2007-02-21 14:54:13 | Re: tsearch in core patch, for inclusion |