Tom Lane wrote:
"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes:
I'm wondering about the testing methodology.
Me too. This test case seems much too far away from real world use
to justify diddling low-level locking behavior; especially a change
that is obviously likely to have very negative effects in other
scenarios. In particular, I think it would lead to complete starvation
of would-be exclusive lockers in the face of competition from a steady
stream of shared lockers. AFAIR the existing behavior was designed
to reduce the odds of that, not for any other purpose.
regards, tom lane
Hi Tom,
The test case is not that far fetched from real world.. Plus if you read
my proposal I clearly mention a tunable for it so that we can set and
hence obviously not impact 99% of the people who don't care about it but
still allow the flexibility of the 1% of the people who do care about
scalability when they go on bigger system. The fact that it is a tunable
(and obviously not the default way) there is no impact to existing
behavior.
My test case clearly shows that Exclusive lockers ARE benefited from it
otherwise I would have not seen the huge impact on throughput.
A tunable does not impact existing behavior but adds flexibility for
those using PostgreSQL on high end systems. Plus doing it the tunable
way on PostgreSQL 8.4 will convince many people that I know to quickly
adopt PostgreSQL 8.4 just because of the benefit it brings on systems
with many cpus/cores/threads.
All I am requesting is for the beta to have that tunable. Its not hard,
people can then quickly try default (off) or on or as Scott Carey
mentioned a more flexible of default, all or a fixed integer number
(for people to experiment).
Regards,
Jignesh
--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
