Re: Straightforward changes for increased SMP scalability - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Straightforward changes for increased SMP scalability
Date
Msg-id 15284.1184602170@sss.pgh.pa.us
Whole thread Raw
In response to Straightforward changes for increased SMP scalability  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Straightforward changes for increased SMP scalability  ("Strong, David" <david.strong@unisys.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> 2. Increase NUM_BUFFER_PARTITIONS from 16 to 256 (or higher).

Do you have any evidence to back up such a large increase?

This change is not free; at the very least it will break
contrib/pg_buffercache, which wants to lock all the partitions at once.
lwlock.c was designed on the assumption that only a pretty small number
of LWLocks would ever be held concurrently, and it will fall over.
I don't think fixing this would be as simple as increasing
MAX_SIMUL_LWLOCKS, because some of the algorithms are O(N^2).

I'd like to see numbers proving that there is useful incremental gain
from going above 32 or 64 partitions, before we start hacking to make
this work.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: minor compiler warning on OpenBSD
Next
From: Martin Pihlak
Date:
Subject: Re: stored procedure stats in collector