Switch to multi-inserts for pg_depend

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Switch to multi-inserts for pg_depend
Date: 2020-08-07 06:16:19
Message-ID: 20200807061619.GA23955@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

This is a continuation of the work that has been previously discussed
here, resulting mainly in e3931d0 for pg_attribute and pg_shdepend:
https://www.postgresql.org/message-id/20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de

I have been looking at the amount of work that could be done
independently for pg_depend, and attached are two patches:
- 0001 switches recordMultipleDependencies() to use multi-inserts.
Contrary to pg_attribute and pg_shdepend, the number of items to
insert is known in advance, but some of them can be skipped if known
as a pinned dependency. The data insertion is capped at 64kB, and the
number of slots is basically calculation from the maximum cap and the
number of items to insert.
- 0002 switches a bunch of code paths to make use of multi-inserts
instead of individual calls to recordDependencyOn(), grouping the
insertions of dependencies of the same time. This relies on the
existing set of APIs to manipulate a set of object addresses, without
any new addition there (no reset-like routine either as I noticed that
it would have been useful in only one place). The set of changes is
honestly a bit bulky here.

I am adding this thread to the next commit fest. Thoughts are
welcome.

Thanks,
--
Michael

Attachment Content-Type Size
0001-Use-multi-inserts-for-pg_depend.patch text/x-diff 5.6 KB
0002-Switch-to-multi-insert-dependencies-for-many-code-pa.patch text/x-diff 39.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-08-07 06:21:24 Re: Switch to multi-inserts for pg_depend
Previous Message Asim Praveen 2020-08-07 06:02:58 Re: [PATCH] - Provide robust alternatives for replace_string