Re: Inefficiency in parallel pg_restore with many tables
От | Alvaro Herrera |
---|---|
Тема | Re: Inefficiency in parallel pg_restore with many tables |
Дата | |
Msg-id | 20230718160511.loirkf5fwjm5ut73@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Inefficiency in parallel pg_restore with many tables (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Inefficiency in parallel pg_restore with many tables
|
Список | pgsql-hackers |
On 2023-Jul-17, Nathan Bossart wrote: > @@ -35,7 +42,11 @@ binaryheap_allocate(int capacity, binaryheap_comparator compare, void *arg) > binaryheap *heap; > > sz = offsetof(binaryheap, bh_nodes) + sizeof(Datum) * capacity; > +#ifdef FRONTEND > + heap = (binaryheap *) pg_malloc(sz); > +#else > heap = (binaryheap *) palloc(sz); > +#endif Hmm, as I recall fe_memutils.c provides you with palloc() in the frontend environment, so you don't actually need this one. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "It takes less than 2 seconds to get to 78% complete; that's a good sign. A few seconds later it's at 90%, but it seems to have stuck there. Did somebody make percentages logarithmic while I wasn't looking?" http://smylers.hates-software.com/2005/09/08/1995c749.html
В списке pgsql-hackers по дате отправления: