Skip site navigation (1) Skip section navigation (2)

Re: column ordering, was Re: [PATCHES] Enums patch v2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2
Date: 2006-12-21 16:59:47
Message-ID: 20900.1166720387@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> I was envisiging the physical number to be fixed and immutable (ie
> storage position = permanent position).

There are two different problems being discussed here, and one of them
is insoluble if we take that position: people would like the system to
automatically lay out tables to minimize alignment overhead and access
costs (eg, put fixed-width columns first).  This is not the same as
"I would like to change the display column order".

It's true that for an ADD COLUMN that doesn't already force a table
rewrite, forcing one to improve packing is probably bad.  My thought
would be that we leave the column storage order alone if we don't have
to rewrite the table ... but any rewriting variant of ALTER TABLE could
optimize the storage order while it was at it.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2006-12-21 17:03:30
Subject: Re: Autovacuum Improvements
Previous:From: Andrew DunstanDate: 2006-12-21 16:57:14
Subject: Re: Release 8.2.0 done, 8.3 development starts

pgsql-patches by date

Next:From: Andrew DunstanDate: 2006-12-21 17:09:46
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2
Previous:From: Martijn van OosterhoutDate: 2006-12-21 16:47:56
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group