| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "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-29 06:52:30 |
| Message-ID: | YXuaLlYJxkmwnTDl@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 28, 2021 at 04:52:48PM -0700, Andres Freund wrote:
> I suspect the reverse lock order release could be tad faster. But I probably
> wouldn't change it either - I was more thinking of some of the other cases
> that deleted the first element, here it's a bit harder to know wether there's
> a chance of a CFI() or such.
Actually, as the list of recovery locks is saved in TopMemoryContext,
wouldn't it be better to keep a per-cell deletion of the list, which
would mean that we'd better do the operation in the reverse order to
make things faster with the new list implementation? But that's what
Andres points at with CFIs in the middle of one list of the hash table
processed?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2021-10-29 07:00:47 | Re: Improve logging when using Huge Pages |
| Previous Message | tanghy.fnst@fujitsu.com | 2021-10-29 06:44:05 | RE: Added schema level support for publication. |