Message-ID: <3DAC2835.2BA5CB60@Yahoo.com>
Date: Tue, 15 Oct 2002 10:37:41 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
Organization: Home
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Alessio Bragadini <alessio@albourne.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Changing Column Order (Was Re: MySQL vs PostgreSQL.)
References: <200210141504.g9EF47W09439@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:
> 
> Alessio Bragadini wrote:
> > On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote:
> >
> > > I cannot think of any reason why changing column order should be
> > > implemented in Postgres. Seems like a waste of time/more code bloat for
> > > something which is strictly asthetic.
> > >
> > > Regardless, I do have collegues/clients who ask when such a feature will
> > > be implemented. Why is this useful?
> >
> > Has column ordering any effect on the physical tuple disposition? I've
> > heard discussions about keeping fixed-size fields at the beginning of
> > the tuple and similar.
> >
> > Sorry for the lame question. :-)
> 
> Yes, column ordering matches physical column ordering in the file, and
> yes, there is a small penalty for accessing any columns after the first
> variable-length column (pg_type.typlen < 0). CHAR() used to be a fixed
> length column, but with TOAST (large offline storage) it became variable
> length too.  I don't think there is much of a performance hit, though.

When was char() fixed size? We had fixed size things like char, char2,
char4 ... char16. But char() is internally bpchar() and has allways been
variable-length.


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #