> Actually the patch I submitted shows no overhead from what I have seen and I > think it is useful depending on workloads where it can be turned on even on > production. Well, unless I'm misunderstanding something, waking all waiters every time could lead to arbitrarily long delays for writers on mostly read-only workloads... and by arbitrarily along, we mean to say "potentially just about forever". That doesn't sound safe for production to me. > I dont think anything is majorly wrong in my system.. Sometimes it is > PostgreSQL locks in play and sometimes it can be OS/system related locks in > play (network, IO, file system, etc). Right now in my patch after I fix > waiting procarray problem other PostgreSQL locks comes into play: > CLogControlLock, WALInsertLock , etc. Right now out of the box we have no > means of tweaking something in production if you do land in that problem. > With the patch there is means of doing knob control to tweak the bottlenecks > of Locks for the main workload for which it is put in production. I'll reiterate my previous objection: I think your approach is too simplistic. I think Tom said it the best: a lot of work has gone into making the locking mechanism lightweight and safe. I'm pretty doubtful that you're going to find a change that is still safe, but performs much better. The discussions by Heikki, Simon, and others about changing the way locks are used or inventing new kinds of locks seem much more promising to me. > Right now.. the standard answer applies.. nope you are running the wrong > workload for PostgreSQL, use a connection pooler or your own application > logic. Or maybe.. you have too many users for PostgreSQL use some > proprietary database. Well I certainly agree that we need to get away from that mentality, although there's nothing particularly evil about a connection pooler... it might not be suitable for every workload, but you haven't specified why one couldn't or shouldn't be used in the situation you're trying to simulate here. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
