Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote:
> Purely out of interest, since the old repo is still there, I had a
> quick look at measuring the overhead, using 8.4's pgbench to run
> two custom scripts: one consisting of a single 'SELECT 1', the
> other having 100 'SELECT 1' - the latter being probably the worst
> case scenario. Running 1,2,4,8 clients and 1000-10000 transactions
> gives an overhead in the 5-8% range [1] (i.e transactions/s
> decrease by this amount with the scheduler turned on [2]). While a
> lot better than 30% (!) it is certainly higher than we'd like.
Hmmm... In my first benchmarks of the serializable patch I was
likewise stressing a RAM-only run to see how much overhead was added
to a very small database transaction, and wound up with about 8%.
By profiling where the time was going with and without the patch,
I narrowed it down to lock contention. Reworking my LW locking
strategy brought it down to 1.8%. I'd bet there's room for similar
improvement in the "active transaction" limit you describe. In fact,
if you could bring the code inside blocks of code already covered by
locks, I would think you could get it down to where it would be hard
to find in the noise.
-Kevin