Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
От | Michael Paquier |
---|---|
Тема | Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions? |
Дата | |
Msg-id | 20190806022446.GA32256@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: