Re: Lock partitions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lock partitions
Date
Msg-id 16328.1158179753@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lock partitions  ("Strong, David" <david.strong@unisys.com>)
Responses Re: Lock partitions  ("Strong, David" <david.strong@unisys.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: CVS commit messages and backpatching
Next
From: Jim Nasby
Date:
Subject: Re: Lock partitions