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

From Daniel Gustafsson
Subject Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
Date
Msg-id 62FA85A1-799B-4B12-A931-B2FAE0560D09@yesql.se
Whole thread Raw
In response to Ought to use heap_multi_insert() for pg_attribute/depend insertions?  (Andres Freund <andres@anarazel.de>)
Responses Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Andres Freund <andres@anarazel.de>)
Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> On 13 Feb 2019, at 19:27, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> 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.

When a colleague was looking at heap_multi_insert in the COPY codepath I
remembered this and took a stab at a WIP patch inspired by this email, while
not following it to the letter.  It’s not going the full route of collecting
all the dependencies for creating a table, but adding ways to perform
multi_heap_insert in the existing codepaths as it seemed like a good place to
start.

It introduces a new function CatalogMultiInsertWithInfo which takes a set of
slots for use in heap_multi_insert, used from recordMultipleDependencies and
InsertPgAttributeTuples (which replace calling InsertPgAttributeTuple
repeatedly).  The code is still a WIP with some kludges, following the show-
early philosophy.

It passes make check and some light profiling around regress suites indicates
that it does improve a bit by reducing the somewhat costly calls.  Is this
along the lines of what you were thinking or way off?

cheers ./daniel


Attachment

pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: PG 12 draft release notes
Next
From: Michael Paquier
Date:
Subject: pg_dump throwing "column number -1 is out of range 0..36" on HEAD