Michael Gould wrote:
> I come from the Sybase world and more SQL Anywhere. This is a feature that
> has been asked for on several occassions. I believe that it is on the
> feature list for V12. The only reason that it has been asked for is because
> of how rows are stored on a page. Only the 1st 256 bytes are stored on the
> initial page and the rest of the data is stored on a overflow page. Those
> columns that are in the first 256 bytes therefore cause less calls to be
> made if a index is created on a column(s) in the first 256 bytes because it
> doesn't need to look at the overflow page. I don't know if this is true or
> not in PostGres. If it isn't then I'm not sure what difference it would
> make other than allowing for "pretty" documentation.
Postgres does not overflow pages. Tuples are stored wholly on a single
page. If they don't fit, large attributes are stored in a separate
table (the TOAST table) and only a pointer is kept in the main table.
So reordering won't give you that benefit.
The other difference it would make is that it'd open the door for
optimizations like storing all fixed-length not nullable attributes
together at the start of the tuple. That should give slightly better
performance.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)
