| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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-31 07:44:27 |
| Message-ID: | DF48E289-7C38-4205-8660-34E2C47EE9D6@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 31 Jul 2020, at 04:42, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Jul 30, 2020 at 11:23:38PM +0200, Daniel Gustafsson wrote:
>> Looks good, thanks. Let's close the CF entry with this and open a new for the
>> pg_depend part when that's done.
>
> I have applied the patch, thanks.
>
> And actually, I have found just after that CREATE DATABASE gets
> severely impacted by the number of slots initialized when copying the
> template dependencies if there are few of them. The fix is as simple
> as delaying the initialization of the slots once we know they will be
> used. In my initial tests, I was using fsync = off, so I missed that.
> Sorry about that. The attached fixes this regression by delaying the
> slot initialization until we know that it will be used. This does not
> matter for pg_attribute as we know in advance the number of attributes
> to insert.
Right, that makes sense. Sorry for missing that, and thanks for fixing.
cheers ./daniel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | torikoshia | 2020-07-31 08:24:44 | Re: Creating a function for exposing memory usage of backend process |
| Previous Message | Masahiko Sawada | 2020-07-31 07:06:38 | Re: Internal key management system |