Re: Switch to multi-inserts for pg_depend - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Switch to multi-inserts for pg_depend
Date
Msg-id 20200814080620.GG2057@paquier.xyz
Whole thread Raw
In response to Re: Switch to multi-inserts for pg_depend  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Switch to multi-inserts for pg_depend  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Aug 13, 2020 at 11:45:52AM -0400, Alvaro Herrera wrote:
> MAX_CATALOG_INSERT_BYTES sounds decent to me.  I mentioned dependency.h
> because I was uncaffeinatedly thinking that this was used with API
> defined there -- but in reality it's used with indexing.h functions, and
> it seems to me that that file would be the place for it.

OK, let's live with indexing.h then.

Regarding the maximum number of slots allocated.  Do people like the
current approach taken by the patch to do a single loop of the
dependency entries at the cost of more allocating perhaps too much for
the array holding the set of TupleTableSlots (the actual slot
initialization happens only if necessary)?  Or would it be preferred
to scan twice the set of dependencies, discarding pinned dependencies
in a first scan to build the list of dependencies that would be
inserted?  This way, you can know the exact amount memory to allocated
for TupleTableSlots, though that's just 64B for each one of them.

I have read today through the patch set of Julien and Thomas to add a
version string to pg_depend, and I get the impression that the
current approach taken by the patch fits better in the whole picture.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Li Japin
Date:
Subject: Re: Terminate the idle sessions
Next
From: Michael Paquier
Date:
Subject: Re: Fix an old description in high-availability.sgml