From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | "sulamul(at)gmail(dot)com" <sulamul(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: inefficient loop in StandbyReleaseLockList() |
Date: | 2021-10-28 16:37:49 |
Message-ID: | 4430A74C-A80D-46DA-AC4A-C0A89D130618@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/28/21, 12:58 AM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> On Thu, Oct 28, 2021 at 03:57:51PM +0900, Kyotaro Horiguchi wrote:
>> However, I'm fine with fixing only StandbyRelaseLockList(), which
>> actually suffers from list_delete_first().
>
> I can also see a large gap between one technique and the other, so
> this looks like a good catch to me coming from Nathan :)
:)
> As it could indeed hurt badly the time it takes to do a shutdown or to
> end recovery, we had better back-patch that down to 13 in my opinion.
+1
> transformGraph and processState seem to be worth improving on
> performance ground, as well, but they look less critical than this
> one but we could do something on HEAD. Skimming through the rest of
> the code, we may be able to improve some areas related to namespaces,
> but that does not seem worth it in terms of code complication.
I just did my own scan through uses of list_delete_first(), and I only
found a couple that might be easily transitioned to the foreach()
approach. I don't think I'm going to pick that up at the moment, but
I'd readily help review such patches if there is a demonstrable
improvement.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-10-28 17:46:49 | Re: [PATCH v2] src/port/snprintf.c: Optimize the common base=10 case in fmtint |
Previous Message | Bruce Momjian | 2021-10-28 16:34:29 | Re: Width of SubTransactionId (hello Postgres PRO) |