Comments on: The need for tunability and measurability http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/ Stay curious! Thu, 02 May 2013 12:36:53 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: Josh Berkus http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/#comment-18102 Josh Berkus Sat, 03 Apr 2010 03:16:56 +0000 http://www.xaprb.com/blog/?p=1708#comment-18102 Baron,

Events with timing information are definitely better than simple counters. However, simple counters are better than nothing at all.

]]> By: Brad http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/#comment-18096 Brad Thu, 01 Apr 2010 14:40:15 +0000 http://www.xaprb.com/blog/?p=1708#comment-18096 “I am also looking for statspack (Oracle) alternative in PostgreSQL and MySQL databases.”

For Postgres, have a look at pgstatspack – it is based on Oracle statspack

http://pgfoundry.org/projects/pgstatspack/

]]> By: Xaprb http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/#comment-18090 Xaprb Tue, 30 Mar 2010 15:02:59 +0000 http://www.xaprb.com/blog/?p=1708#comment-18090 Josh, I suspected there were several versions of the story. I find that counters (number of rows read) are all but useless. You cannot do any meaningful performance analysis with them in the absence of timing information.

]]> By: Josh Berkus http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/#comment-18085 Josh Berkus Tue, 30 Mar 2010 05:10:14 +0000 http://www.xaprb.com/blog/?p=1708#comment-18085 “Someone claimed to have offered patches with a detailed set of instrumentation (I’d also heard this story from someone else at the same company, six months ago in a different place). He told me that the maintainers had declined it on the basis of the added overhead.”

This seems unlikely at best. Certainly people have posted instrumentation patches which have been rejected; but these have been rejected because:

a) They were poorly written, or

b) They only worked on one OS, or

c) They instrumented something which nobody else found useful to measure (at least not in the way presented), or

d) They had demonstrated *hefty* overhead (as in 2% for a single measurement), or

e) The method of instrumentation used did not integrate with anything in our existing instrumentation or any standards.

I’ve seen all these cases in proposed instrumentation patches; in some cases the author (esp. Greg Smith and Itagaki Takahiro) reworks the patch to make it acceptable, and in other cases potential contributors take their ball and go home. That’s OSS, and you can’t really control people’s motivations.

I don’t think there’s anyone in the community who wants less visibility into operation, resources and performance. It’s one of the most frequent demands of our user base. Doing it well is also hard and unsexy (to date, not ONE Summer of Code proposal has been about instrumentation), so it’s going to be slow going for the forseeable future.

Still, every PostgreSQL release since 8.0 has had a few more things you could monitor or query than the last release.

]]> By: Denish Patel http://www.xaprb.com/blog/2010/03/28/the-need-for-tunability-and-measurability/#comment-18079 Denish Patel Mon, 29 Mar 2010 14:53:27 +0000 http://www.xaprb.com/blog/?p=1708#comment-18079 I am also looking for statspack (Oracle) alternative in PostgreSQL and MySQL databases.

]]>