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 |
Message-ID: | 20190806022446.GA32256@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.)
--
Michael
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 |