Re: Inefficiency in parallel pg_restore with many tables - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Inefficiency in parallel pg_restore with many tables
Date
Msg-id 20230913224753.GA1237642@nathanxps13
Whole thread Raw
In response to Re: Inefficiency in parallel pg_restore with many tables  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Inefficiency in parallel pg_restore with many tables
List pgsql-hackers
On Wed, Sep 13, 2023 at 11:34:50AM -0700, Nathan Bossart wrote:
> On Sun, Sep 10, 2023 at 12:35:10PM -0400, Tom Lane wrote:
>> Other than those nitpicks, I like v6.  I'll mark this RfC.
> 
> Great.  I've posted a v8 with your comments addressed in order to get one
> more round of cfbot coverage.  Assuming those tests pass and there is no
> additional feedback, I'll plan on committing this in the next few days.

Upon closer inspection, I found a rather nasty problem.  The qsort
comparator expects a TocEntry **, but the binaryheap comparator expects a
TocEntry *, and we simply pass the arguments through to the qsort
comparator.  In v9, I added the requisite ampersands.  I'm surprised this
worked at all.  I'm planning to run some additional tests to make sure this
patch set works as expected.

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

Attachment

pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Support prepared statement invalidation when result types change
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Jumble the CALL command in pg_stat_statements