| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew T. O'Connor | 2006-12-21 17:03:30 | Re: Autovacuum Improvements |
| Previous Message | Andrew Dunstan | 2006-12-21 16:57:14 | Re: Release 8.2.0 done, 8.3 development starts |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2006-12-21 17:09:46 | Re: column ordering, was Re: [PATCHES] Enums patch v2 |
| Previous Message | Martijn van Oosterhout | 2006-12-21 16:47:56 | Re: column ordering, was Re: [PATCHES] Enums patch v2 |