Re: Any better plan for this query?..

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Dimitri <dimitrik(dot)fr(at)gmail(dot)com>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-12 14:34:30
Message-ID: 4A0988F6.7090709@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Dimitri wrote:
> Hi Stefan,
>
> sorry, I did not have a time to bring all details into the toolkit -
> but at least I published it instead to tell a "nice story" about :-)

fair point and appreciated. But it seems important that benchmarking
results can be verified by others as well...

>
> The client process is a binary compiled with libpq. Client is
> interpreting a scenario script and publish via SHM a time spent on
> each SQL request. I did not publish sources yet as it'll also require
> to explain how to compile them :-)) So for the moment it's shipped as
> a freeware, but with time everything will be available (BTW, you're
> the first who asking for sources (well, except IBM guys who asked to
> get it on POWER boxes, but it's another story :-))

well there is no licence tag(or a copyright notice) or anything als
associated with the download which makes it a bit harder than it really
needs to be.
The reason why I was actually looking for the source is that all my
available benchmark platforms are none of the ones you are providing
binaries for which kinda reduces its usefulness.

>
> What is good is each client is publishing *live* its internal stats an
> we're able to get live data and follow any kind of "waves" in
> performance. Each session is a single process, so there is no
> contention between clients as you may see on some other tools. The
> current scenario script contains 2 selects (representing a Read
> transaction) and delete/insert/update (representing Write
> transaction). According a start parameters each client executing a
> given number Reads per Write. It's connecting on the beginning and
> disconnecting at the end of the test.

well I have seen clients getting bottlenecked internally (like wasting
more time in getting rid/absorbing of the actual result than it took the
server to generate the answer...).
How sure are you that your "live publishing of data" does not affect the
benchmark results(because it kinda generates an artifical think time)
for example?
But what I get from your answer is that you are basically doing one
connect/disconnect per client and the testcase you are talking about has
256 clients?

Stefan

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2009-05-12 15:00:00 Re: Any better plan for this query?..
Previous Message Robert Haas 2009-05-12 14:21:32 Re: Any better plan for this query?..