Re: improving concurrent transactin commit rate - Mailing list pgsql-hackers

From Sam Mason
Subject Re: improving concurrent transactin commit rate
Date
Msg-id 20090325175602.GD12225@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: improving concurrent transactin commit rate  (Kenneth Marshall <ktm@rice.edu>)
Responses Re: improving concurrent transactin commit rate  (Kenneth Marshall <ktm@rice.edu>)
List pgsql-hackers
On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote:
> On Wed, Mar 25, 2009 at 03:58:06PM +0000, Sam Mason wrote:
> >   #!/bin/bash
> >   nclients=$1
> >   ittrs=$2
> >   function gensql  {
> >       echo "INSERT INTO bm (c,v) VALUES ('$1','0');"
> >       for (( i = 1; i < $ittrs; i++ )); do
> >           echo "UPDATE bm SET v = '$i' WHERE c = '$1';"
> >       done
> >       echo "DELETE FROM bm WHERE c = '$1';"
> >   }
> >   for (( c = 0; c < $nclients; c++)); do
> >       gensql $c | psql -Xq -f - &
> >   done
> >   for (( c = 0; c < $nclients; c++)); do
> >       wait
> >   done
> 
> Are you sure that you are able to actually drive the load at the
> high end of the test regime? You may need to use multiple clients
> to simulate the load effectively.

Notice that the code is putting things into the background and then
waiting for them to finish so there will be multiple clients.  Or maybe
I'm misunderstanding what you mean.

I've just tried modifying the code to write the generated SQL out to
a set of files first and this speeds things up by about 6% (the 48
client case goes from taking ~42 seconds to ~39 seconds) indicating that
everything is probably OK with the test harness.  Also note that this 6%
improvement will be linear and across the board and hence should just
appear as slightly reduced performance for my system.  As I'm not really
interested in absolute performance and more in how the system scales as
load increases this will negate this effect even further.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: GIN versus zero-key queries
Next
From: Josh Berkus
Date:
Subject: Re: [pgsql-www] shut down pgsql-interfaces (was Re: Function C and INOUT parameters)