Re: Inefficiency in parallel pg_restore with many tables
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2023-09-01T20:52:48Z
Lists: pgsql-hackers
On Fri, Sep 01, 2023 at 04:00:44PM -0400, Robert Haas wrote: > In hindsight, I think that making binaryheap depend on Datum was a bad > idea. I think that was my idea, and I think it wasn't very smart. > Considering that people have coded to that decision up until now, it > might not be too easy to change at this point. But in principle I > guess you'd want to be able to make a heap out of any C data type, > rather than just Datum, or just Datum in the backend and just void * > in the frontend. Yeah, something similar to simplehash for binary heaps could be nice. That being said, I don't know if there's a strong reason to specialize the implementation for a given C data type in most cases. I suspect many callers are just fine with dealing with pointers (e.g., I wouldn't store an entire TocEntry in the array), and smaller types like integers are already stored directly in the array thanks to the use of Datum. However, it _would_ allow us to abandon this frontend/backend void */Datum kludge, which is something. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Remove open-coded binary heap in pg_dump_sort.c.
- 559bc1732180 17.0 landed
-
Convert pg_restore's ready_list to a priority queue.
- 9bfd44bbde42 17.0 landed
-
Add function for removing arbitrary nodes in binaryheap.
- c103d073819a 17.0 landed
-
Make binaryheap available to frontend code.
- 5af0263afd7b 17.0 landed