Tomas Vondra wrote: > 1) change the order of columns in "SELECT *" > > - display columns so that related ones grouped together > (irrespectedly whether they were added later, etc.) > > - keep columns synced with COPY > > - requires user interface (ALTER TABLE _ ALTER COLUMN _ SET ORDER _)
Not sure about the "ORDER #" syntax. In ALTER ENUM we have "AFTER <value>" and such .. I'd consider that instead. > 2) optimization of physical order (efficient storage / tuple deforming) > > - more efficient order for storage (deforming) > > - may be done manually by reordering columns in CREATE TABLE > > - should be done automatically (no user interface required) A large part of it can be done automatically: for instance, not-nullable fixed length types ought to come first, because that enables the attcacheoff optimizations in heaptuple.c to fire for more columns. But what column comes next? The offset of the column immediately after them can also be cached, and so it would be faster to obtain than other attributes. Which one to choose here is going to be a coin toss in most cases, but I suppose there are cases out there which can benefit from having a particular column there. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
