On Thu, 5 Jul 2007, Jan Wieck wrote:
Original pgbench reported 39, 37 and 33 TPS. Having my patch applied it
reported 40, 38 and 33 TPS. Inserting a "\usleep 1" after the update to
accounts of a default equivalent script changed those numbers to 40, 37 and
33. I interpret that as "does not change observed performance".
Tell you what: put your work into a patch, send it to the list, and I'll
test that it doesn't degrade results for you. If your pgbench results are
in the <40 TPS range even with that low of a scale, you're not in a
position to tell whether it has a negative performance impact. That
select statement you're fiddling with can turn into a bottleneck at high
client loads, and from your description I can't tell if you've made that
worse, but you'll never see it unless you're pushing, say,
1000 TPS and >50 clients. Also: 3 pgbench results at one client load
is quite a bit short of proving no impact on performance; I'll queue up 50
or so, which is where I start to trust results from that unruly tool.
This is actually a feature I'd be kind of interested to have, because it
would allow you to pass two (or more) script files to pgbench and adjust
the transaction mix. What happens when you do that right now is that
inevitably all the clients get blocked at once on whatever the hardest to
execute transaction is, and the results are kind of deceptive as a result.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
