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

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Ought to use heap_multi_insert() for pg_attribute/depend insertions?
Date: 2019-02-13 18:27:37
Message-ID: 20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Turns out in portions of the regression tests a good chunk of the
runtime is inside AddNewAttributeTuples() and
recordMultipleDependencies()'s heap insertions. Looking at a few
profiles I had lying around I found that in some production cases
too. ISTM we should use heap_multi_insert() for both, as the source
tuples ought to be around reasonably comfortably.

For recordMultipleDependencies() it'd obviously better if we collected
all dependencies for new objects, rather than doing so separately. Right
now e.g. the code for a new table looks like:

recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);

recordDependencyOnOwner(RelationRelationId, relid, ownerid);

recordDependencyOnNewAcl(RelationRelationId, relid, 0, ownerid, relacl);

recordDependencyOnCurrentExtension(&myself, false);

if (reloftypeid)
referenced.classId = TypeRelationId;
referenced.objectId = reloftypeid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);

and it'd obviously be more efficient to do that once if we went to using
heap_multi_insert() in the dependency code. But I suspect even if we
just used an extended API in AddNewAttributeTuples() (for the type /
collation dependencies), it'd be a win.

I'm not planning to work on this soon, but I though it'd be worthwhile
to put this out there (even if potentially just as a note to myself).


Andres Freund


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-02-13 18:33:03 Re: subscriptionCheck failures on nightjar
Previous Message Tom Lane 2019-02-13 18:24:03 Re: subscriptionCheck failures on nightjar