Re: inefficient loop in StandbyReleaseLockList()
От | Andres Freund |
---|---|
Тема | Re: inefficient loop in StandbyReleaseLockList() |
Дата | |
Msg-id | 20211028221424.6wtcse3qkbf2cmqo@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: inefficient loop in StandbyReleaseLockList() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: inefficient loop in StandbyReleaseLockList()
|
Список | 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
В списке pgsql-hackers по дате отправления: