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 <gentosaker@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