Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date
Msg-id alpine.DEB.2.02.1307131759050.3991@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
List pgsql-hackers
Hello Greg,

> There's a refactoring possible here that seems to make this whole class of 
> problem go away.  If I change pgbench so that PQfinish isn't called for any 
> client until *all* of the clients are actually finished with transactions, 
> the whole issue goes away.

Sure. If the explanation is that because of the load the OS is just 
switching to a "postgres" process while PQfinish is being called, then 
waiting for the end of other transactions means that "postgres" processes 
don't have anything to do anymore, so process switching is much less 
likely, so nothing would show up... However this is really hiding the 
underlying fact from the measures rather than solving anything, IMHO.

> I'm going to package that hack the right way into its own little change,
> revisit the throttling code, and then this all should wrap up nicely.

My 0.02€: if it means adding complexity to the pgbench code, I think that 
it is not worth it. The point of pgbench is to look at a steady state, not 
to end in the most graceful possible way as far as measures are concerned. 
On the other end, if it does not add too much complexity, why not!

> I'd like to get this one out of the commitfest so I can move onto 
> looking at something else.

Thanks.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Next
From: Tom Lane
Date:
Subject: Re: Regex pattern with shorter back reference does NOT work as expected