Re: Challenges with huge postgresql deployments in 300+ TBs - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Challenges with huge postgresql deployments in 300+ TBs
Date
Msg-id D2E355FF-9D49-4242-B004-2FA7844031B6@gmail.com
Whole thread
In response to Challenges with huge postgresql deployments in 300+ TBs  (kavya chandren <kavyachandren@gmail.com>)
Responses Re: Challenges with huge postgresql deployments in 300+ TBs
List pgsql-general
> On 8 Oct 2026, at 09:05, kavya chandren <kavyachandren@gmail.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
havechanged. 

- Oracle doesn’t (did not?) differentiate between '' and NULL, while Postgres does. Make sure you get the right values
inthe right places. Safest bet is probably to import your data using column types in PG that allow for '’-values, so
thatyou don’t get interrupted by errors from NOT NULL constraints and the like, and fix those later. That’s probably
lessof 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
encodingthough, 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
practicaluse of VARCHAR(n) are much better, with no practical benefits for CHAR(n). That is, apart from formatting
monospacetext 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.




pgsql-general by date:

Previous
From: Juan Rodrigo Alejandro Burgos Mella
Date:
Subject: Re: Challenges with huge postgresql deployments in 300+ TBs
Next
From: kavya chandren
Date:
Subject: Re: Challenges with huge postgresql deployments in 300+ TBs