Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
Date
Msg-id 20190806022446.GA32256@paquier.xyz
Whole thread Raw
In response to Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Aug 05, 2019 at 04:45:59PM +0900, Michael Paquier wrote:
> +   if (referenced->numrefs == 1)
> +       recordDependencyOn(depender, &referenced->refs[0], behavior);
> +   else
> +       recordMultipleDependencies(depender,
> +                                  referenced->refs, referenced->numrefs,
> +                                  behavior);
> This makes me wonder if we should not just add a shortcut in
> recordMultipleDependencies() to use recordDependencyOn if there is
> only one reference in the set.  That would save the effort of a multi
> insert for all callers of recordMultipleDependencies() this way,
> including the future ones.  And that could also be done independently
> of the addition of InsertPgAttributeTuples(), no?

A comment in heap_multi_insert() needs to be updated because it
becomes the case with your patch:
     /*
      * We don't use heap_multi_insert for catalog tuples yet, but
      * better be prepared...
      */

There is also this one in DecodeMultiInsert()
      * CONTAINS_NEW_TUPLE will always be set currently as multi_insert
      * isn't used for catalogs, but better be future proof.

(I am going to comment on the assertion issue on the other thread, I
got some suggestions about it.)
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Next
From: Alex
Date:
Subject: pg can create duplicated index without any errors even warnning