From: | veem v <veema0000(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | Lok P <loknath(dot)73(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-13 19:58:24 |
Message-ID: | CAB+=1TV0EnXiD3FYnzbgp+zH5mC0oO2SO3sHV7aEr1-2DBXRig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 13 Aug 2024 at 19:39, Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:
> On Sat, Aug 10, 2024 at 5:06 PM Lok P <loknath(dot)73(at)gmail(dot)com> wrote:
>
>
>> Can someone through some light , in case we get 5-6hrs downtime for this
>> change , then what method should we choose for this Alter operation?
>>
>
> We can't really answer that. Only you know what resources you have, what
> risk/reward you are willing to handle, and how long things may take. For
> that latter item, your best bet is to try this out on the same/similar
> hardware and see how long it takes. Do a smaller table and extrapolate if
> you need to. Or promote one of your replicas offline and modify that. I've
> given you a low-risk / medium-reward option with check constraints, but for
> the ALTER TABLE options you really need to try it and see (on non-prod).
>
>>
>>
What about if the OP opt a strategy something as below,
1) Detaching the partitions 2)Altering individual partitions with required
column type and length 3)Altering the table 4)Attaching the partitions back
to the main table
This should be faster and also a controlled fashion for each partition
individually.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter J. Holzer | 2024-08-13 20:53:51 | Re: Column type modification in big tables |
Previous Message | Lok P | 2024-08-13 19:56:36 | Re: Column type modification in big tables |