Re: Column type modification in big tables

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Lok P <loknath(dot)73(at)gmail(dot)com>
Cc: Alban Hertroys <haramrae(at)gmail(dot)com>, sud <suds1434(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Column type modification in big tables
Date: 2024-08-17 15:55:56
Message-ID: CAKAnmmKjWVdPHUFVStspC_20XSp8bVSSJa4j3RXnHNPqtQJdfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Aug 15, 2024 at 4:41 PM Lok P <loknath(dot)73(at)gmail(dot)com> wrote:

> Additionally , if we are okay with the 7.5hrs of down time , is my
> calculation/extrapolation of total time consumption based on a sample
> table, for direct alter, accurate? Because, in that case , I was thinking
> it's less complex and also less error prone to just do it in a single alter
> command rather than going for multiple steps of detach, alter, attach
> partition.
>

Well, it's meant to get you a ballpark figure, but yes, it seems as though
you will probably okay, But for something this critical involving
production downtime, I would try out the exact command and see how long it
takes on a test system. Restore a backup (you have backups I hope) or use
pg_basebackup to make a copy of your prod system somewhere.

Cheers,
Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message jian he 2024-08-19 00:00:00 Re: Emitting JSON to file using COPY TO
Previous Message Dimitrios Apostolou 2024-08-17 15:35:39 Re: array_agg() does not stop aggregating according to HAVING clause