From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, 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-03 16:07:09 |
Message-ID: | 9738eb42-9ea6-1a15-6fd3-bf711bfdcb2d@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-12-02 Fr 12:40, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 2022-12-02 Fr 09:18, Tom Lane wrote:
>>> 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.
> Well, what this would lose is the ability to selectively restore
> individual large objects using "pg_restore -L". I'm not sure who
> out there might be depending on that, but if we assume that's the
> empty set I fear we'll find out it's not. So a workaround switch
> seemed possibly worth the trouble. I don't have a position yet
> on which way ought to be the default.
>
>
OK, fair point. I suspect making the batched mode the default would gain
more friends than enemies.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matheus Alcantara | 2022-12-03 17:34:57 | Re: mprove tab completion for ALTER EXTENSION ADD/DROP |
Previous Message | Ilya Gladyshev | 2022-12-03 15:13:30 | Re: CREATE INDEX CONCURRENTLY on partitioned index |