On Tue, 15 Nov 2022 at 23:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> BTW, while nosing around this code I came across this statement
> (procarray.c, about line 4550 in HEAD):
>
> * ... To add XIDs to the array, we just insert
> * them into slots to the right of the head pointer and then advance the head
> * pointer. This wouldn't require any lock at all, except that on machines
> * with weak memory ordering we need to be careful that other processors
> * see the array element changes before they see the head pointer change.
> * We handle this by using a spinlock to protect reads and writes of the
> * head/tail pointers. (We could dispense with the spinlock if we were to
> * create suitable memory access barrier primitives and use those instead.)
> * The spinlock must be taken to read or write the head/tail pointers unless
> * the caller holds ProcArrayLock exclusively.
>
> Nowadays we've *got* those primitives. Can we get rid of
> known_assigned_xids_lck, and if so would it make a meaningful
> difference in this scenario?
I think you could do that *as well*, since it does act as an overhead
but that is not related to the main issues:
* COMMITs: xids are removed from the array by performing a binary
search - this gets more and more expensive as the array gets wider
* SNAPSHOTs: scanning the array for snapshots becomes more expensive
as the array gets wider
Hence more frequent compression is effective at reducing the overhead.
But too frequent compression slows down the startup process, which
can't then keep up.
So we're just looking for an optimal frequency of compression for any
given workload.
--
Simon Riggs http://www.EnterpriseDB.com/
