> 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