Re: Proposal of tunable fix for scalability of 8.4

On 3/12/09 6:29 PM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:

>> Its worth ruling out given that even if the likelihood is small, the fix is
>> easy.  However, I don¹t see the throughput drop from peak as more
>> concurrency is added that is the hallmark of this problem < usually with a
>> lot of context switching and a sudden increase in CPU use per transaction.
>
> The problem is that the proposed "fix" bears a strong resemblence to
> attempting to improve your gas mileage by removing a few non-critical
> parts from your card, like, say, the bumpers, muffler, turn signals,
> windshield wipers, and emergency brake.
>

The fix I was referring to as easy was using a connection pooler -- as a
reply to the previous post. Even if its a low likelihood that the connection
pooler fixes this case, its worth looking at.

>
> While it's true that the car
> might be drivable in that condition (as long as nothing unexpected
> happens), you're going to have a hard time convincing the manufacturer
> to offer that as an options package.
>

The original poster's request is for a config parameter, for experimentation
and testing by the brave. My own request was for that version of the lock to
prevent possible starvation but improve performance by unlocking all shared
at once, then doing all exclusives one at a time next, etc.

>
> I think that changing the locking behavior is attacking the problem at
> the wrong level anyway. If someone want to look at optimizing
> PostgreSQL for very large numbers of concurrent connections without a
> connection pooler... at least IMO, it would be more worthwhile to
> study WHY there's so much locking contention, and, on a lock by lock
> basis, what can be done about it without harming performance under
> more normal loads? The fact that there IS locking contention is sorta
> interesting, but it would be a lot more interesting to know why.
>
> ...Robert
>

I alluded to the three main ways of dealing with lock contention elsewhere.
Avoiding locks, making finer grained locks, and making locks faster.
All are worthy. Some are harder to do than others. Some have been heavily
tuned already. Its a case by case basis. And regardless, the unfair lock
is a good test tool.