Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qNMKR-004m85-I8 for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Jul 2023 23:48:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qNMKP-000Zmu-AW for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Jul 2023 23:48:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qNMKP-000Zmm-0x for pgsql-hackers@lists.postgresql.org; Sat, 22 Jul 2023 23:48:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qNMKL-001DFh-A4 for pgsql-hackers@lists.postgresql.org; Sat, 22 Jul 2023 23:48:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 36MNloLU1225142; Sat, 22 Jul 2023 19:47:50 -0400 From: Tom Lane To: Nathan Bossart cc: Alvaro Herrera , Andrew Dunstan , pgsql-hackers@lists.postgresql.org Subject: Re: Inefficiency in parallel pg_restore with many tables In-reply-to: <20230722231941.GA2020225@nathanxps13> References: <20230718045701.GA1090171@nathanxps13> <20230718160511.loirkf5fwjm5ut73@alvherre.pgsql> <20230718160713.GA1139177@nathanxps13> <20230720190644.GA1724613@nathanxps13> <20230722231941.GA2020225@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Sat, 22 Jul 2023 16:19:41 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1225140.1690069670.1@sss.pgh.pa.us> Date: Sat, 22 Jul 2023 19:47:50 -0400 Message-ID: <1225141.1690069670@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart 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