Re: Switch to multi-inserts for pg_depend

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: Switch to multi-inserts for pg_depend
Date: 2020-08-14 08:06:20
Message-ID: 20200814080620.GG2057@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-08-14 08:15:20 Re: Fix an old description in high-availability.sgml
Previous Message Li Japin 2020-08-14 08:02:27 Re: Terminate the idle sessions