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

From Tom Lane
Subject Re: Inefficiency in parallel pg_restore with many tables
Date
Msg-id 1225141.1690069670@sss.pgh.pa.us
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
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Jul 20, 2023 at 12:06:44PM -0700, Nathan Bossart wrote:
>> One item that requires more thought is binaryheap's use of Datum.  AFAICT
>> the Datum definitions live in postgres.h and aren't available to frontend
>> code.  I think we'll either need to move the Datum definitions to c.h or to
>> adjust binaryheap to use "void *".

> In v3, I moved the Datum definitions to c.h.  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'm quite uncomfortable with putting Datum in c.h.  I know that the
typedef is merely a uintptr_t, but this solution seems to me to be
blowing all kinds of holes in the abstraction, because exactly none
of the infrastructure that goes along with Datum is or is ever likely
to be in any frontend build.  At the very least, frontend code that
refers to Datum will be misleading as hell.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Inefficiency in parallel pg_restore with many tables
Next
From: jian he
Date:
Subject: Re: PG 16 draft release notes ready