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  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Giving more detail in pg_upgrade errormessage
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Inefficiency in parallel pg_restore with many tables