Re: Upgrade questions

Got it.

Thank you, that's very helpful: we could delete quite a few of the rows
before we did the operation and cut way down on the size of the table
before we issue the update. Trimming the table size down seems obvious
enough, but that's good confirmation that it will very much help. And
there are quite a few indexes that I've discovered are useless, so dropping
those will speed things up too.

Looking online I see that a query progress indicator is a commonly
requested feature, but isn't yet implemented, so it sound like my best bet
is to clone the db on similar hardware, take all the advice offered here,
and just see how it performs.

Thanks to everyone for the feedback,
Carson

On Tue, Mar 13, 2012 at 6:32 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

> On 03/13/12 6:10 PM, Carson Gross wrote:
>
>> As a follow up, is the upgrade from integer to bigint violent? I assume
>> so: it has to physically resize the column on disk, right?
>>
>>
> I think we've said several times, any ALTER TABLE ADD/ALTER COLUMN like
> that will cause every single tuple (row) of the table to be updated.
> when rows are updated, the new row is written, then the old row is flagged
> for eventual vacuuming.
>
>
>
> --
> john r pierce N 37, W 122
> santa cruz ca mid-left coast
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>