Re: 8.2 Partition lock changes and resource queuing.

Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> The other approach I wondered about was arranging for the resource locks
>> and related data structures to all use an *additional* partition lock -
>> which would mean faking a LOCKTAG that always hashed to
>> NUM_LOCK_PARTITIONS, and using that everywhere in the resource code...
>
> That seems mighty ugly, as well as defeating the purpose of spreading
> the LWLock contention around evenly.

Yes - and possibly confusing to amend later, when I (or someone else)
had forgotten why it was done that way...

> I'd go for letting the resource
> locks go into their natural hash partitions, and making a separate LWLock
> for your other data structures. (Some day you might get to the point of
> wanting to partition the other data structures, in which case you'd be
> glad you separated the locks.)

Great, thanks for the quick reply!

Cheers

Mark