Re: Column storage positions

Bruce Momjian escribió:
> 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.

Yes, but the "cache offset" stuff is still significant, so there will be
some benefit in putting all the fixed-length attributes at the start of
the tuple, and varlena atts grouped at the end.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.