Re: inefficient loop in StandbyReleaseLockList()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sulamul(at)gmail(dot)com, bossartn(at)amazon(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inefficient loop in StandbyReleaseLockList()
Date: 2021-10-28 22:14:24
Message-ID: 20211028221424.6wtcse3qkbf2cmqo@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-10-28 15:07:48 -0700, Andres Freund wrote:
> On 2021-10-28 15:57:51 +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.
>
> We should be careful with changes like this, because there's some advantages
> in the while(!empty) pattern too. Iterating over the whole list doesn't work
> if there's any other modifications to the list, or if there's a chance of
> errors. For the latter there just needs to be a CHECK_FOR_INTERRUPTS()
> somewhere...

Which leads to to wonder whether the better fix would be to switch to deleting
the last element, but still use the while (!empty) style. That should convert
the O(n^2) due to 1cff1b9 back to O(n). It might or might not be faster/slower
than using foreach(), but it should be within the same ballpark.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-28 22:24:51 Re: inefficient loop in StandbyReleaseLockList()
Previous Message Andres Freund 2021-10-28 22:07:48 Re: inefficient loop in StandbyReleaseLockList()