IMHO one of the possible solutions is to review the table and storage externaly the stable columns. So when you run 'alter table xxxx' it was less expensive (i never test this, but maybe its true :P )
So the mutable columns will be separated from the others and the phisical structure could be more light to changes. Emanauel 2009/3/30, A B <gentosa...@gmail.com>: > Hi, > In the next project I'm going to have a number of colums in my tables, > but I don't know how many, they change. They all use integers as > datatype though.. One day, I get 2 new columns, a week later I loose > one column, and so on in a random pattern. > > I will most likely have a few million rows of data so I just wonder if > there are any problems with running > alter table x add column ..... > or > alter table x drop column ..... > > Adding a column, will it place data "far away" on the disc so that > select * from x where id=y will result in not quite optimal > performance since it has to fetch columns from a lot of different > places? > Will deleting a column result in a lot of empty space that will anoy > me later on? > > Are there any other clever solutions of this problem? > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Emanuel Calvo Franco Sumate al ARPUG ! (www.postgres-arg.org - www.arpug.com.ar) ArPUG / AOSUG Member Postgresql Support & Admin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
