| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> | 
|---|---|
| To: | Ron <ronljohnsonjr(at)gmail(dot)com> | 
| Cc: | pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: What to watch out for when ALTERing NUMERIC(38,0) to BIGINT? | 
| Date: | 2022-07-28 15:19:38 | 
| Message-ID: | CAKFQuwZ8su=VAeyNZ6Wj5cU1OoZLQB+B3iPWh49k2yjk4o4ujQ@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-admin | 
On Thu, Jul 28, 2022 at 8:13 AM Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
> AWS RDS Postgresql 12.10
>
>
> We've got tables with columns of data type NUMERIC(38,0) which are a
> legacy from an Oracle migration.
>
> Besides what's mentioned in
> https://www.postgresql.org/docs/12/ddl-alter.html#id-1.5.4.8.10, what
> happens *internally* when I run:
> ALTER TABLE foo ALTER COLUMN bar TYPE BIGINT;
>
> I'm thinking mostly of record fragmentation.
>
>
IIUC, that would be the silver lining in all of this - the rewritten table
would have zero fragmentation and bloat.  You don't get clustering so the
actual physical ordering will still be random but each page will contain
all live tuples contiguously placed.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-07-28 15:26:39 | Re: What to watch out for when ALTERing NUMERIC(38,0) to BIGINT? | 
| Previous Message | Ron | 2022-07-28 15:13:10 | What to watch out for when ALTERing NUMERIC(38,0) to BIGINT? |