Re: Switch to multi-inserts for pg_depend - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Switch to multi-inserts for pg_depend
Date
Msg-id 20200903145049.GA14188@alvherre.pgsql
Whole thread Raw
In response to Re: Switch to multi-inserts for pg_depend  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Switch to multi-inserts for pg_depend  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
I agree, this version looks much better, thanks.  Two very minor things:

On 2020-Sep-03, Michael Paquier wrote:

> @@ -76,11 +77,23 @@ recordMultipleDependencies(const ObjectAddress *depender,
>  
>      dependDesc = table_open(DependRelationId, RowExclusiveLock);
>  
> +    /*
> +     * Allocate the slots to use, but delay initialization until we know that
> +     * they will be used.  The slot initialization is the costly part, and the
> +     * exact number of dependencies inserted cannot be known in advance as it
> +     * depends on what is pinned by the system.
> +     */

I'm not sure you need the second sentence in this comment; keeping the
"delay initialization until ..." part seems sufficient.  If you really
want to highlight that initialization is costly, maybe just say "delay
costly initialization".

> +        /*
> +         * Record the Dependency.  Note we don't bother to check for duplicate
> +         * dependencies; there's no harm in them.
> +         */

No need to uppercase "dependency".  (I know this is carried forward from
prior comment, but it was equally unnecessary there.)

>      /*
>       * Allocate the slots to use, but delay initialization until we know that
> -     * they will be used.
> +     * they will be used.  A full scan of pg_shdepend is done to find all the
> +     * dependencies from the template database to copy.  Their number is not
> +     * known in advance and the slot initialization is the costly part.
>       */

As above, this change is not needed.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: [NBTREE] Possible NULL pointer dereference (backend/access/nbtree/nbutils.c)
Next
From: Dave Page
Date:
Subject: Re: Kerberos support broken on MSVC builds for Windows x64?