From: | michael(at)paquier(dot)xyz |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions? |
Date: | 2020-07-01 09:24:18 |
Message-ID: | 20200701092418.GB10408@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 30, 2020 at 02:25:07PM +0200, Daniel Gustafsson wrote:
> Ok, once the final state of this patchset is known I can take a stab at
> recording multiple dependencies with different behaviors as a separate
> patchset.
Thanks. I have applied 0001 and 0002 today, in a reversed order
actually.
> If we do, we need to keep the cap consistent across all callers, else we'll end
> up with an API without an abstraction to make it worth more than saving a few
> lines of quite simple to read code. Currently this is the case, but that might
> not always hold, so not sure it if it's worth it.
I am not sure either, still it looks worth thinking about it.
Attached is a rebased version of the last patch. What this currently
holds is just the switch to heap_multi_insert() for the three catalogs
pg_attribute, pg_depend and pg_shdepend. One point that looks worth
debating about is to how much to cap the data inserted at once. This
uses 64kB for all three, with a number of slots chosen based on the
size of each record, similarly to what we do for COPY.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
catalog_multi_insert-v12.patch | text/x-diff | 25.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-07-01 09:26:44 | Re: Autovacuum on partitioned table (autoanalyze) |
Previous Message | Daniel Gustafsson | 2020-07-01 09:18:52 | Re: [HACKERS] Cached plans and statement generalization |