Re: small pg_dump code cleanup - Mailing list pgsql-hackers

From Neil Conway
Subject Re: small pg_dump code cleanup
Date
Msg-id CAOW5sYZtaR=QP4Ygc_gDvUrFwas1xmZR4yQbNCuYjHrcd066yA@mail.gmail.com
Whole thread Raw
In response to Re: small pg_dump code cleanup  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Wed, Jun 5, 2024 at 12:37 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
What about collectXXX() to match similar functions in pg_dump.c (e.g.,
collectRoleNames(), collectComments(), collectSecLabels())?

sgtm.
 
> (2) These functions malloc() a single ntups * sizeof(struct) allocation and
> then index into it to fill-in each struct before entering it into the hash
> table. It might be more straightforward to just malloc each individual
> struct.

That'd increase the number of allocations quite significantly, but I'd be
surprised if that was noticeable outside of extreme scenarios.  At the
moment, I'm inclined to leave these as-is for this reason and because I
doubt it'd result in much cleanup, but I'll yield to the majority opinion
here.

As you say, I'd be surprised if the performance difference is noticeable. Personally I don't think the marginal performance win justifies the hit to readability, but I don't feel strongly about it.

Neil

pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Next
From: Jeff Davis
Date:
Subject: Re: Extension security improvement: Add support for extensions with an owned schema