Comments on: Seeking input on a badness score for query execution http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/ Stay curious! Thu, 09 Feb 2012 20:41:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Fernando Ipar http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/#comment-16647 Fernando Ipar Thu, 09 Jul 2009 14:10:27 +0000 http://www.xaprb.com/blog/?p=1140#comment-16647 Baron: The advices on inspecting the number of rows returned are good. Since you're asking for pointers in CS literature, I'd suggest anything in Big 'O' notation, since what you need is more of a theoretical and architecture agnostic way of determining how bad a query is. Together with the number of rows, I'd compute the data type length of each column, this should give you a better idea of how much info the server will have to process and transfer back to get the results to the client. I'd also take into account if columns can take NULLs or not, since this puts a performance penalty on MySQL, but you know a lot more about this than me :P Either way, my ideal algorithm would use these information plus the output from explain, to take into account what stages MySQL goes through to bring you the data. But maybe I divert. Baron:

The advices on inspecting the number of rows returned are good. Since you’re asking for pointers in CS literature, I’d suggest anything in Big ‘O’ notation, since what you need is more of a theoretical and architecture agnostic way of determining how bad a query is.

Together with the number of rows, I’d compute the data type length of each column, this should give you a better idea of how much info the server will have to process and transfer back to get the results to the client.

I’d also take into account if columns can take NULLs or not, since this puts a performance penalty on MySQL, but you know a lot more about this than me :P
Either way, my ideal algorithm would use these information plus the output from explain, to take into account what stages MySQL goes through to bring you the data.

But maybe I divert.

]]> By: Shlomi Noach http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/#comment-16607 Shlomi Noach Sun, 28 Jun 2009 05:29:26 +0000 http://www.xaprb.com/blog/?p=1140#comment-16607 Baron, Joining Tim's advice. But also, back from my Math/CS studies, in order to give more weight to larger numbers, you usually use the log() function. So for example, to see how far apart two numbers a,b are, you'd use something like: log(|a|)*|a-b|/|a| |a-b|/|a| gives you the percent in growth from a to b; multiplying by log(|a|) gives very little weight to "small" numbers (whatever that means) and more weight to "large" numbers. Baron,
Joining Tim’s advice.

But also, back from my Math/CS studies, in order to give more weight to larger numbers, you usually use the log() function.
So for example, to see how far apart two numbers a,b are, you’d use something like:
log(|a|)*|a-b|/|a|

|a-b|/|a| gives you the percent in growth from a to b;
multiplying by log(|a|) gives very little weight to “small” numbers (whatever that means) and more weight to “large” numbers.

]]> By: Tim McCormack http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/#comment-16605 Tim McCormack Sat, 27 Jun 2009 00:42:07 +0000 http://www.xaprb.com/blog/?p=1140#comment-16605 I think you want to get in touch with a statistician. They have tools to determine what constitutes a "significant" difference. I think you want to get in touch with a statistician. They have tools to determine what constitutes a “significant” difference.

]]> By: rich http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/#comment-16604 rich Sat, 27 Jun 2009 00:17:11 +0000 http://www.xaprb.com/blog/?p=1140#comment-16604 It seems the reason why going from 100rows to 125rows (a 25% change) is not really likely to be significant is because it probably doesn't cost any I/O. Leaving aside what's possible, it would seem like you really want to measure the I/O cost of the query, and perhaps combine it with a CPU cost of the query. (Alternatively, have two separate badness measures.) It seems the reason why going from 100rows to 125rows (a 25% change) is not really likely to be significant is because it probably doesn’t cost any I/O. Leaving aside what’s possible, it would seem like you really want to measure the I/O cost of the query, and perhaps combine it with a CPU cost of the query. (Alternatively, have two separate badness measures.)

]]> By: Arjen Lentz http://www.xaprb.com/blog/2009/06/26/seeking-input-on-a-badness-score-for-query-execution/#comment-16603 Arjen Lentz Fri, 26 Jun 2009 22:32:54 +0000 http://www.xaprb.com/blog/?p=1140#comment-16603 Baron, right now we tend to use some info from the queryplan as provided by the microslow patch. Mem/disk temp tables, mem/disk sorts, as well as # rows examined/returned. Rather than timing, it looks more at the flow of the query through the server, given the current dataset. It does of course also give time, so you can take it into account as well. A "badness' score could be a good extra for mk-query-digest. Baron, right now we tend to use some info from the queryplan as provided by the microslow patch. Mem/disk temp tables, mem/disk sorts, as well as # rows examined/returned. Rather than timing, it looks more at the flow of the query through the server, given the current dataset. It does of course also give time, so you can take it into account as well.

A “badness’ score could be a good extra for mk-query-digest.

]]>