Re: Switch to multi-inserts for pg_depend

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2020-08-14T18:23:16Z
Lists: pgsql-hackers
On 2020-Aug-14, Michael Paquier wrote:

> 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.

It seems a bit silly to worry about allocating just the exact amount
needed; the current approach looked fine to me.  The logic to keep track
number of used slots used is baroque, though -- that could use a lot of
simplification.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Switch to multi-inserts when registering dependencies for many code paths

  2. Use multi-inserts for pg_depend