Re: Simple Column reordering - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Simple Column reordering
Date
Msg-id 1172218105.3874.256.camel@silverbirch.site
Whole thread Raw
In response to Re: Simple Column reordering  ("Andrew Dunstan" <andrew@dunslane.net>)
Responses Re: Simple Column reordering  (Lukas Kahwe Smith <smith@pooteeweet.org>)
Re: Simple Column reordering  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Re: Simple Column reordering  (Peter Eisentraut <peter_e@gmx.net>)
Re: Simple Column reordering  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2007-02-22 at 20:07 -0600, Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > I propose that at CREATE TABLE time, the column ordering is re-ordered
> > so that the table columns are packed more efficiently. This would be a
> > physical re-ordering, so that SELECT * and COPY without explicit column
> > definitions would differ from the original CREATE TABLE statement.
> >
> > This would be an optional feature, off by default, controlled by a
> > USERSET GUC
> >     optimize_column_order = off (default) | on
> >
> 
> 
> Umm, you want a GUC setting to enable standards-breaking behaviour and
> that will be obsolete when we do column ordering right, which is not
> likely to be more than one release away, and could even still happen in
> this coming release?

If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the ordering to
be the same as it has specified, AFAICS. Please correct me and I will
withdraw. Practical issues seem far stronger drivers than standards
issues here, which is why the parameter would default=off.

If the full implementation exists and works, I would welcome it. This
proposal is really aimed at what we do if that doesn't occur; we must
wait to see if it will. I see that many users would want to get
something sooner rather than later. That isn't a commercial perspective,
I see that as a PostgreSQL advocacy perspective.

I also see that we are forcing change into the on-disk format of heaps
in this release. If we defer this to another release then we would be
effectively changing the on-disk format again in next release.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Lukas Kahwe Smith
Date:
Subject: Re: SCMS question
Next
From: Lukas Kahwe Smith
Date:
Subject: Re: Simple Column reordering