Re: Reduce ProcArrayLock contention

>>
>
> Numbers look impressive and definitely shows that the idea is worth pursuing. I tried patch on my laptop. Unfortunately, at least for 4 and 8 clients, I did not see any improvement. 

>

I can't help in this because I think we need somewhat

bigger m/c to test the impact of patch.

I was telling that fact even without my patch. Basically I have

tried by commenting ProcArrayLock in ProcArrayEndTransaction.

> But those who don't get the lock will sleep and hence the contention is moved somewhere else, at least partially.  
>

Sure, if contention is reduced at one place it will move

to next lock.

  

No, autovacuum generates I/O due to which sometimes there

is more variation in Write tests.

  

I can do something like that if others also agree with this new

API in LWLock series, but personally I don't think LWLock.c is

the right place to expose API for this work.  Broadly the work

we are doing can be thought of below sub-tasks.

1. Advertise each backend's xid.

2. Push all backend's except one on global list.

3. wait till some-one wakes and check if the xid is cleared,

   repeat untll the xid is clear

4. Acquire the lock

5. Pop all the backend's and clear each one's xid and used

   their published xid to advance global latestCompleteXid.

6. Release Lock

7. Wake all the processes waiting for their xid to be cleared

   and before waking mark that Xid of the backend is clear.

So among these only step 2 can be common among different

algorithms, other's need some work specific to each optimization.

>

> Regarding the patch, the compare-and-exchange function calls that you've used would work only for 64-bit machines, right? You would need to use equivalent 32-bit calls on a 32-bit machine.
>

I thought that internal API will automatically take care of it,

example for msvc it uses _InterlockedCompareExchange64

which if doesn't work on 32-bit systems or is not defined, then

we have to use 32-bit version, but I am not certain about

that fact.