On 27.2.2015 21:42, Josh Berkus wrote: > On 02/27/2015 12:25 PM, Tomas Vondra wrote: >> On 27.2.2015 21:09, Josh Berkus wrote: >>> Tomas, >>> >>> So for an API, 100% of the use cases I have for this feature would be >>> satisfied by: >>> >>> ALTER TABLE ______ ALTER COLUMN _____ SET ORDER # >>> >>> and: >>> >>> ALTER TABLE _____ ADD COLUMN colname coltype ORDER # >> >> Yes, I imagined an interface like that. Just to be clear, you're >> talking about logical order (and not a physical one), right? > > Correct. The only reason to rearrange the physical columns is in > order to optimize, which presumably would be carried out by a utility > command, e.g. VACUUM FULL OPTIMIZE.
I was thinking more about CREATE TABLE at this moment, but yeah, VACUUM FULL OPTIMIZE might do the same thing. >> If we ignore the system columns, the current implementation assumes >> that the values in each of the three columns (attnum, attlognum >> and attphysnum) are distinct and within 1..natts. So there are no >> gaps and you'll always set the value to an existing one (so yes, >> shuffling is necessary). >> >> And yes, that certainly requires an exclusive lock on the >> pg_attribute (I don't think we need a lock on the table itself). > > If MVCC on pg_attribute is good enough to not lock against concurrent > "SELECT *", then that would be lovely. Yeah, I think this will need a bit more thought. We certainly don't want blocking queries on the table, but we need a consistent list of column definitions from pg_attribute. -- Tomas Vondra 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