Re: Lock partitions
| От | Tom Lane | 
|---|---|
| Тема | Re: Lock partitions | 
| Дата | |
| Msg-id | 16328.1158179753@sss.pgh.pa.us обсуждение исходный текст | 
| Ответ на | Re: Lock partitions ("Strong, David" <david.strong@unisys.com>) | 
| Ответы | Re: Lock partitions | 
| Список | pgsql-hackers | 
"Strong, David" <david.strong@unisys.com> writes:
> We have some results for you. We left the buffer partition locks at 128
> as this did not seem to be a concern and we're still using 25 backend
> processes. We ran tests for 4, 8 and 16 lock partitions. 
> For 4 lock partitions, it took 620 seconds to acquire locks and 32
> seconds to release locks. The test produced 199.95 TPS.
> For 8 lock partitions, it took 505 seconds to acquire locks and 31
> seconds to release locks. The test produced 201.16 TPS.
> For 16 lock partitions, it took 362 seconds to acquire locks and 22
> seconds to release locks. The test produced 200.75 TPS.
> And, just for grins, using 128 buffer and 128 lock partitions, took 235
> seconds to acquire locks and 22 seconds to release locks. The test
> produced 203.24 TPS.
[ itch... ]  I can't help thinking there's something wrong with this;
the wait-time measurements seem sane, but why is there essentially no
change in the TPS result?
The above numbers are only for the lock-partition LWLocks, right?
What are the totals --- that is, how much time is spent blocked
vs. processing overall?
        regards, tom lane
		
	В списке pgsql-hackers по дате отправления: