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