From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Inefficiency in parallel pg_restore with many tables |
Date: | 2023-07-23 05:57:03 |
Message-ID: | 20230723055703.GA2421212@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 22, 2023 at 07:47:50PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> I first tried modifying
>> binaryheap to use "int" or "void *" instead, but that ended up requiring
>> some rather invasive changes in backend code, not to mention any extensions
>> that happen to be using it.
I followed through with the "void *" approach (attached), and it wasn't as
bad as I expected.
> I wonder whether we can't provide some alternate definition or "skin"
> for binaryheap that preserves the Datum API for backend code that wants
> that, while providing a void *-based API for frontend code to use.
I can give this a try next, but it might be rather #ifdef-heavy.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
v4-0001-use-void-instead-of-Datum-in-binaryheap.patch | text/x-diff | 17.6 KB |
v4-0002-make-binaryheap-available-to-frontend.patch | text/x-diff | 3.3 KB |
v4-0003-expand-binaryheap-api.patch | text/x-diff | 2.1 KB |
v4-0004-use-priority-queue-for-pg_restore-ready_list.patch | text/x-diff | 14.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-07-23 08:17:25 | Re: remaining sql/json patches |
Previous Message | jian he | 2023-07-23 04:45:17 | Re: PG 16 draft release notes ready |