| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Inefficiency in parallel pg_restore with many tables |
| Date: | 2023-07-18 16:05:11 |
| Message-ID: | 20230718160511.loirkf5fwjm5ut73@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-07-18 16:07:13 | Re: Inefficiency in parallel pg_restore with many tables |
| Previous Message | Tom Lane | 2023-07-18 16:04:20 | Re: Giving more detail in pg_upgrade errormessage |