Re: Inefficiency in parallel pg_restore with many tables
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-07-15T18:19:16Z
Lists: pgsql-hackers
Hi, On 2023-07-15 13:47:12 -0400, Tom Lane wrote: > I wonder if we could replace the sorted ready-list with a priority heap, > although that might be complicated by the fact that pop_next_work_item > has to be capable of popping something that's not necessarily the > largest remaining job. Another idea could be to be a little less eager > to sort the list every time; I think in practice scheduling wouldn't > get much worse if we only re-sorted every so often. Perhaps we could keep track of where the newly inserted items are, and use insertion sort or such when the number of new elements is much smaller than the size of the already sorted elements? As you say, a straight priority heap might not be easy. But we could just open code using two sorted arrays, one large, one for recent additions that needs to be newly sorted. And occasionally merge the small array into the big array, once it has gotten large enough that sorting becomes expensive. We could go for a heap of N>2 such arrays, but I doubt it would be worth much. Greetings, Andres Freund
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