From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com>, Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Switching Primary Keys to BigInt |
Date: | 2020-07-21 23:32:40 |
Message-ID: | 14e326d2-7ee3-be5a-feb5-4e6c43425fb8@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/21/20 2:18 PM, Mohamed Wael Khobalatte wrote:
>> > test_(aklaver)5432> alter table change_seq alter COLUMN id set data type
>> bigint;
>> ALTER TABLE
>> test_(aklaver)5432> \d change_seq
>> Table "public.change_seq"
>> Column | Type | Collation | Nullable | Default
>> --------+--------+-----------+----------+----------------------------------------
>>
>> id | bigint | | not null |
>> nextval('change_seq_id_seq'::regclass)
>> Indexes:
>> "change_seq_pkey" PRIMARY KEY, btree (id)
>
> This is significant downtime, since it locks exclusively, no? We want to
> avoid that.
Yeah, I thought the int --> bigint would not do a table rewrite. Testing
showed otherwise. Forget that idea.
>
> > Side note- EOL for 9.6 is coming next year so just a plug for
> upgrading when possible, perhaps utilizing pglogical to get to v11 or 12.
>
> Yep, we are painfully aware. The id growth will beat us to it, so we
> need to deal with that first.
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Mohamed Wael Khobalatte | 2020-07-22 01:08:03 | Re: Switching Primary Keys to BigInt |
Previous Message | Michał Lis | 2020-07-21 21:35:22 | Problem with pg_service.conf |