Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?
Date: 2019-08-06 02:24:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.)

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alex 2019-08-06 02:34:19 pg can create duplicated index without any errors even warnning
Previous Message Stephen Frost 2019-08-06 02:16:16 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions