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

Reply via email to