Re: Inefficiency in parallel pg_restore with many tables

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09-04 23:08:29
Message-ID: 20230904230829.GA3826808@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 02, 2023 at 11:55:21AM -0700, Nathan Bossart wrote:
> I ended up hacking together a (nowhere near committable) patch to see how
> hard it would be to allow using any type with binaryheap. It doesn't seem
> too bad.

I spent some more time on this patch and made the relevant adjustments to
the rest of the set.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v7-0001-Allow-binaryheap-to-use-any-type.patch text/x-diff 24.4 KB
v7-0002-Make-binaryheap-available-to-frontend-code.patch text/x-diff 3.6 KB
v7-0003-Add-function-for-removing-arbitrary-nodes-in-bina.patch text/x-diff 2.9 KB
v7-0004-Convert-pg_restore-s-ready_list-to-a-priority-que.patch text/x-diff 15.8 KB
v7-0005-Remove-open-coded-binary-heap-in-pg_dump_sort.c.patch text/x-diff 6.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Soumyadeep Chakraborty 2023-09-04 23:43:59 Re: brininsert optimization opportunity
Previous Message Noah Misch 2023-09-04 21:13:18 Re: backtrace_functions emits trace for any elog