From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump: Remove "blob" terminology |
Date: | 2022-12-02 17:26:29 |
Message-ID: | 34c6f0df-7dc9-9a8c-42e5-c35b55d51711@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-12-02 Fr 09:18, Tom Lane wrote:
> we really need to do something about situations with $BIGNUM
> large objects. Currently those tend to run pg_dump or pg_restore
> out of memory because of TOC bloat, and we've seen multiple field
> reports of that actually happening.
>
> The scheme I've vaguely thought about, but not got round to writing,
> is to merge all blobs with the same owner and ACL into one TOC entry.
> One would hope that would get it down to a reasonable number of
> TOC entries in practical applications. (Perhaps there'd need to be
> a switch to make this optional.)
+1 for fixing this. Your scheme seems reasonable. This has been a pain
point for a long time. I'm not sure what we'd gain by making the fix
optional.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-12-02 17:28:29 | Re: refactor ExecGrant_*() functions |
Previous Message | Andres Freund | 2022-12-02 17:18:12 | Re: Add tracking of backend memory allocated to pg_stat_activity |