| From: | kavya chandren <kavyachandren(at)gmail(dot)com> |
|---|---|
| To: | Alban Hertroys <haramrae(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Challenges with huge postgresql deployments in 300+ TBs |
| Date: | 2026-10-08 11:09:30 |
| Message-ID: | CAPXWBGYTazf_an=81Hn-BOCOz6x8giYU96A4b9RwbitSvswabw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Thanks Alban for your inputs around migration. My major concern was around
operational challenges (if any) for such huge database
On Thu, Oct 8, 2026 at 3:39 PM Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
>
> > On 8 Oct 2026, at 09:05, kavya chandren <kavyachandren(at)gmail(dot)com> wrote:
>
> (…)
>
> > 6. Finding equivalents of oracle items (which is common during any
> oracle to postgres migration)
>
> There are a number of key differences between Oracle and Postgres that I’m
> aware of. This is by no means an exhaustive list, nor may it still be very
> accurate today; The last version of Oracle I worked with was Oracle 12i, so
> things may have changed.
>
> - Oracle doesn’t (did not?) differentiate between '' and NULL, while
> Postgres does. Make sure you get the right values in the right places.
> Safest bet is probably to import your data using column types in PG that
> allow for '’-values, so that you don’t get interrupted by errors from NOT
> NULL constraints and the like, and fix those later. That’s probably less of
> a hassle (even with 300+TB) than trying to correct the data beforehand.
>
> - Oracle has CLOBs, where you can dump those values in a (type) text field
> in PG. That may introduce a character encoding though, on which some values
> could fail if you don’t take care of those beforehand.
>
> - Oracle has BLOBs, where PG has a separate LOB table or bytea fields.
> Either approach has its cons and pros.
>
> - Old Oracle DDL may still contain CONNECT BY PRIOR recursion. PG uses
> recursive CTE’s.
>
> - Space-padded strings (CHAR(n)) in Postgres are supported, but they are
> usually advised against. Both performance and practical use of VARCHAR(n)
> are much better, with no practical benefits for CHAR(n). That is, apart
> from formatting monospace text output without processing (console style
> output or matrix printers and the like).
>
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Johnson | 2026-10-08 11:09:47 | Re: Challenges with huge postgresql deployments in 300+ TBs |
| Previous Message | Alban Hertroys | 2026-10-08 10:09:31 | Re: Challenges with huge postgresql deployments in 300+ TBs |