Comments on: Optimize this? http://blog.xcski.com/2008/04/13/optimize-this Everything I used to bore people on newsgroups and mailing lists with, now in one inconvenient place. Fri, 22 Aug 2008 00:39:59 +0000 http://wordpress.org/?v=2.6.1 By: Joe D http://blog.xcski.com/2008/04/13/optimize-this#comment-85641 Joe D Mon, 14 Apr 2008 03:40:25 +0000 http://blog.xcski.com/?p=1321#comment-85641 No idea if this will have any effect, but try changing that "a.type in (blah)" to "b.type in (blah)". No idea if this will have any effect, but try changing that “a.type in (blah)” to “b.type in (blah)”.

]]> By: richard http://blog.xcski.com/2008/04/13/optimize-this#comment-85637 richard Sun, 13 Apr 2008 23:18:29 +0000 http://blog.xcski.com/?p=1321#comment-85637 yes, as soon as you apply a function to a column in (most) databases you will force a tablescan. The inequality may also force a tablescan. I think the way around this is to precompute the column (i.e. have a column whose value is 1 if ((chart_map & 7) != 0) ). (Oracle, at least, allows function indexes). I don't know which parts of the query are constants, and which parts are inputs, so that's my best suggestion for now. If this column really is a bitmap, think about exploding it into separate columns of type char(1). The other thing to be aware of is that if you're going to hit multiple indexes with your comparators then the optimizer may also decide that it's faster to simply do a tablescan because hitting multiple indexes, and merging the results is slower than accessing the base data. On a point of style you should always qualify which table the columns come from; you might know that category is in b and chart_map is in a, but the programmer that comes after you might not (and by creating a column of the same name in one of the other tables will break your code without even touching it). final thought... if some of the comparators radically restrict the data set, then you might try using subselects. yes, as soon as you apply a function to a column in (most) databases you will force a tablescan. The inequality may also force a tablescan. I think the way around this is to precompute the column (i.e. have a column whose value is 1 if ((chart_map & 7) != 0) ). (Oracle, at least, allows function indexes). I don’t know which parts of the query are constants, and which parts are inputs, so that’s my best suggestion for now. If this column really is a bitmap, think about exploding it into separate columns of type char(1).

The other thing to be aware of is that if you’re going to hit multiple indexes with your comparators then the optimizer may also decide that it’s faster to simply do a tablescan because hitting multiple indexes, and merging the results is slower than accessing the base data.

On a point of style you should always qualify which table the columns come from; you might know that category is in b and chart_map is in a, but the programmer that comes after you might not (and by creating a column of the same name in one of the other tables will break your code without even touching it).

final thought… if some of the comparators radically restrict the data set, then you might try using subselects.

]]>