From: Robert Haas <robertmhaas@gmail.com>
To: Jignesh K. Shah <J.K.Shah@sun.com>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Thu, 19 Mar 2009 16:49:49 -0400
Message-ID: <603c8f070903191349p5e8fb00as2816581d584fcefd@mail.gmail.com> (raw)
In-Reply-To: <49C17190.9050003@sun.com>
References: <603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com>
<C5E680C6.3790%scott@richrelevance.com>
<603c8f070903181425r6fff6f7eq11e2dac6e867a7d0@mail.gmail.com>
<49C17190.9050003@sun.com>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: robertmhaas@gmail.com, J.K.Shah@sun.com, scott@richrelevance.com, gsmith@gregsmith.com, Kevin.Grittner@wicourts.gov
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <603c8f070903191349p5e8fb00as2816581d584fcefd@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox