Re: inefficient loop in StandbyReleaseLockList() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: inefficient loop in StandbyReleaseLockList()
Date
Msg-id YXpX6VQHW/Afk5AB@paquier.xyz
Whole thread Raw
In response to Re: inefficient loop in StandbyReleaseLockList()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: inefficient loop in StandbyReleaseLockList()
List pgsql-hackers
On Thu, Oct 28, 2021 at 03:57:51PM +0900, Kyotaro Horiguchi wrote:
> I found several other instances of the pattern
> "while(list){list_delete_first(); /*no-break*/}" in
> llvm_release_context, gistProcessEmptyingQueue, AtEOXact_Namespace and
> maybe transformGraph and processState in trgm_regexp.c.  We might want
> to apply this technique to the three first, and maybe to the last two.
>
> 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.

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

Attachment

pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication
Next
From: Amit Langote
Date:
Subject: Re: Data is copied twice when specifying both child and parent table in publication