From: Bruce Momjian on 10 Sep 2006 19:57 I see this in the CVS commits for 8.2. Did we determine the proper number of lock partitions? Should it be based on the number of buffers or concurrent sessions allowed? Divide the lock manager's shared state into 'partitions', so as to reduce contention for the former single LockMgrLock. Per my recent proposal. I set it up for 16 partitions, but on a pgbench test this gives only a marginal further improvement over 4 partitions --- we need to test more scenarios to choose the number of partitions. -- Bruce Momjian bruce(a)momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
From: Tom Lane on 10 Sep 2006 20:30 Bruce Momjian <bruce(a)momjian.us> writes: > I see this in the CVS commits for 8.2. Did we determine the proper > number of lock partitions? Should it be based on the number of buffers > or concurrent sessions allowed? No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for a number of reasons, and there is absolutely zero evidence to justify making any effort (and spending any cycles) on a variable value. It would be nice to see some results from the OSDL tests with, say, 4, 8, and 16 lock partitions before we forget about the point though. Anybody know whether OSDL is in a position to run tests for us? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
From: Tom Lane on 11 Sep 2006 11:29 Mark Wong <markw(a)osdl.org> writes: > Tom Lane wrote: >> It would be nice to see some results from the OSDL tests with, say, 4, >> 8, and 16 lock partitions before we forget about the point though. >> Anybody know whether OSDL is in a position to run tests for us? > Yeah, I can run some dbt2 tests in the lab. I'll get started on it. > We're still a little bit away from getting the automated testing for > PostgreSQL going again though. Great, thanks. The thing to twiddle is LOG2_NUM_LOCK_PARTITIONS in src/include/storage/lwlock.h. You need a full backend recompile after changing it, but you shouldn't need to initdb, if that helps. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
From: Mark Wong on 11 Sep 2006 11:20 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: >> I see this in the CVS commits for 8.2. Did we determine the proper >> number of lock partitions? Should it be based on the number of buffers >> or concurrent sessions allowed? > > No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for a > number of reasons, and there is absolutely zero evidence to justify > making any effort (and spending any cycles) on a variable value. > > It would be nice to see some results from the OSDL tests with, say, 4, > 8, and 16 lock partitions before we forget about the point though. > Anybody know whether OSDL is in a position to run tests for us? Yeah, I can run some dbt2 tests in the lab. I'll get started on it. We're still a little bit away from getting the automated testing for PostgreSQL going again though. Mark ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
From: Simon Riggs on 12 Sep 2006 04:36
On Mon, 2006-09-11 at 11:29 -0400, Tom Lane wrote: > Mark Wong <markw(a)osdl.org> writes: > > Tom Lane wrote: > >> It would be nice to see some results from the OSDL tests with, say, 4, > >> 8, and 16 lock partitions before we forget about the point though. > >> Anybody know whether OSDL is in a position to run tests for us? > > > Yeah, I can run some dbt2 tests in the lab. I'll get started on it. > > We're still a little bit away from getting the automated testing for > > PostgreSQL going again though. > > Great, thanks. The thing to twiddle is LOG2_NUM_LOCK_PARTITIONS in > src/include/storage/lwlock.h. You need a full backend recompile > after changing it, but you shouldn't need to initdb, if that helps. IIRC we did that already and the answer was 16... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |