| From: | Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Michael Lewis <mlewis(at)entrata(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Switching Primary Keys to BigInt |
| Date: | 2020-07-22 18:23:27 |
| Message-ID: | CABZeWdxCGX-WsrV+Cbz5f4L5UqxFoa_agKzCOrP5=6otpCEDZA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Jul 22, 2020 at 11:13 AM Daniel Verite <daniel(at)manitou-mail(dot)org>
wrote:
> Mohamed Wael Khobalatte wrote:
>
> > We lock the table as a precaution, with the understanding that we are
> > undergoing a "small" downtime to finish replacing the int id by the new
> > bigint
>
> Ah, sorry I overlooked that most row updates are done
> pre-transaction in a preliminary step:
> /* in batches, we update all the rows to new_id = id */
>
No worries. I suppose the answer to the original question, which is how to
avoid a table scan when adding a primary key constraint to a newly
backfilled column is "there is no way"? Downtime might be at least as long
as the table scan.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2020-07-22 18:32:45 | Re: Doubt in mvcc |
| Previous Message | Bruce Momjian | 2020-07-22 18:06:00 | Re: Transaction control in SECURITY DEFINER procedures |