Re: column ordering, was Re: [PATCHES] Enums patch
От | Bruce Momjian |
---|---|
Тема | Re: column ordering, was Re: [PATCHES] Enums patch |
Дата | |
Msg-id | 200612201620.kBKGKGW17573@momjian.us обсуждение исходный текст |
Ответ на | Re: column ordering, was Re: [PATCHES] Enums patch v2 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: column ordering, was Re: [PATCHES] Enums patch v2
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > > Now, we are rewriting the table from scratch anyway, the on disk > > format is changing. What is stopping us from switching the column > > order at the same time. The only thing I can think is that the > > catalogs will need more work to update them. It's a middle sized > > price to pay for being able to reorder the columns in the table. One > > of the problems I have is wanting to add a column in the middle of the > > table, but FK constraints stop me dropping the table to do the > > reorder. If ALTER TABLE would let me stick it in the middle and > > rewrite the table on disk, I wouldn't care. It's likely that I would > > be rewriting the table anyway. And by specifying AT POSITION, or > > BEFORE/AFTER you know for big tables it's going to take a while. > > > > This isn't really a compromise. Remember that this discussion started > with consideration of optimal record layout (minimising space use by > reducing or eliminating alignment padding). The above proposal really > does nothing for that. I assume space waste will be mostly fixed when we have 0/1 byte headers for varlena data types. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: