From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Phil Currier <pcurrier(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Column storage positions |
Date: | 2007-02-21 13:54:07 |
Message-ID: | 20070221135407.GL25424@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Phil Currier escribió:
> Inspired by this thread [1], and in particular by the idea of storing
> three numbers (permanent ID, on-disk storage position, display
> position) for each column, I spent a little time messing around with a
> prototype implementation of column storage positions to see what kind
> of difference it would make. The results were encouraging: on a table
> with 20 columns of alternating smallint and varchar(10) datatypes,
> selecting the max() of one of the rightmost int columns across 1
> million rows ran around 3 times faster.
[snipped]
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.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-02-21 13:59:30 | Re: --enable-xml instead of --with-libxml? |
Previous Message | Florian G. Pflug | 2007-02-21 13:37:46 | Re: tsearch in core patch, for inclusion |