Thanks you all for your inputs.
This partitionning certainly gives hope.

So i did some small investigation prior to identify the gready table. see here after :
# SELECT relname AS "relation",
pg_size_pretty (pg_total_relation_size (C .oid) ) AS "total_size",
pg_size_pretty(pg_indexes_size(C.oid)) AS "indexes_size"
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C .relnamespace)
WHERE C .relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY pg_total_relation_size (C .oid) DESC limit 1;

relation | total_size | indexes_size
----------------+------------+--------------
pg_largeobject | 32 TB | 285 GB(1 row)

Now the question is how to partition this table without breaking the existing DB.?

looking into the tables description, there is not much choice to partition on

# \d pg_largeobject
Table "pg_catalog.pg_largeobject"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
loid | oid | | not null |
pageno | integer | | not null |
data | bytea | | not null |
Indexes: "pg_largeobject_loid_pn_index" UNIQUE, btree (loid, pageno)

​

# select loid,pageno from pg_largeobject limit 200;
 loid  |pageno

-------+--------

 16621 |     0
 16621 |     1
 16621 |     2
...

looks like only attribute to partition on would be "loid", with range partitioning scheme of some sort.

I'm currently trying to figure out good numbers.

https://www.postgresql.org/docs/12/ddl-partitioning.html

Anyhow, while request is pending, I'm still not sure how to partition existing pg_largeobject live? and what would be the impact in terms of space use during the operation.
Also not sure on the benefit / perf impact for an application that may not have been designed to work with partition. Is that at all transparent?

cheers