Re: Changing Column Order (Was Re: MySQL vs PostgreSQL.)
Bruce Momjian <pgman@candle.pha.pa.us>
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Alessio Bragadini <alessio@albourne.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2002-10-16T01:18:34Z
Lists: pgsql-hackers, pgsql-general
Jan Wieck wrote: > 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. char() was fixed size only in that you could cache the column offsets for char() becuase it was always the same width on disk before TOAST. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073