Re: 8.2 Partition lock changes and resource queuing.
От | Tom Lane |
---|---|
Тема | Re: 8.2 Partition lock changes and resource queuing. |
Дата | |
Msg-id | 24440.1165799767@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 8.2 Partition lock changes and resource queuing. (Mark Kirkwood <markir@paradise.net.nz>) |
Ответы |
Re: 8.2 Partition lock changes and resource queuing.
|
Список | pgsql-hackers |
Mark Kirkwood <markir@paradise.net.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. 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.) regards, tom lane
В списке pgsql-hackers по дате отправления: