home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / informix / 2789 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  3.3 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Two index query optimization problem
  5. Message-ID: <1992Dec15.164949.6788@informix.com>
  6. Date: 15 Dec 92 16:49:49 GMT
  7. References: <1992Dec12.000653.7004@anasaz>
  8. Sender: news@informix.com (Usenet News)
  9. Distribution: usa
  10. Organization: Informix Software, Inc.
  11. Lines: 65
  12.  
  13. Devin Wala writes:
  14. >
  15. >
  16. >I'm having some problems with Informix over optimizing my query. 
  17. >I have a table with > 500000 rows and I can't get Informix to
  18. >use what I deem to be the "correct" index.
  19. >
  20. >There are two indexes on the table:
  21. >
  22. >   index1: unique index on A, B;
  23. >   index2: unique index on C, D, A, B;
  24. >
  25. >The problem I'm having is that I can't run a query with A and B mentioned
  26. >in the WHERE clause that will use index2.  I suspect that the optimizer
  27. >is looking at the query and saying; hey, I got A, I got B, I've got a unique
  28. >index1 on both A and B.  Look no further, I am set dudes and dudettes, and 
  29. >I am outta here! (optimizers talk like that you know).
  30. >
  31. >This would be fine if my queries were of the form:  
  32. >
  33. >   WHERE C=value AND D=value A=value AND B=value; 
  34. >   
  35. >However, one of my queries is of the form:
  36. >
  37. >   WHERE C=value AND D=value A>value AND B=value; 
  38. >
  39. >so it doesn't _really_ have a value for A.  I do need to have both
  40. >indexes for performance reasons.  I don't think that setting optimization
  41. >to low is an option in this case since it effects the whole database
  42. >back end and not just the single query.  We are running Online V 4.10.UF2, 
  43. >SQL V 4.00.UG2 on a Pyramid MI Server.
  44. >
  45. >Does anyone have any ideas, suggestions, or comments?  Any help you
  46. >can provide is greatly appreciated.
  47.  
  48. Of course the optimizer is choosing the first index, as it will certainly
  49. be more selective than the second index.  Given that you have a > clause,
  50. the second index could only be used for positioning to the beginning of
  51. the potential set.  Added to this the fact that you will only be able to
  52. use 3/4 of the 4 part index (once you hit the >, it can't use any part
  53. beyond that) and the first index, being unique and having both parts available
  54. as literals in the query, is preferable.
  55.  
  56. You could try changing the second index to be C,D,B,A, which would allow it
  57. to use all 4 parts of the index.  The optimizer may still decide the first one
  58. is better.  
  59.  
  60. Make sure you run UPDATE STATISTICS so that the optimizer has recent stats to
  61. do its analysis with.
  62.  
  63. If you still see the other index used, and are convinced that the first would
  64. be better, try dropping the first index and timing the query (which would
  65. be using the second index for sure).  Also note the cost and estimated rows
  66. returned from sqexplain.out.  Now recreate the first index and do the same
  67. thing again.  The purpose of this exercise is to see if your suspicions are
  68. correct (i.e. that the second index would be "better").  Quite often, I've
  69. found that what I thought would be a "better" index was not so, and that
  70. the optimizer actually made the better choice.
  71.  
  72. Dave
  73. -- 
  74. Disclaimer: These opinions are not those of Informix Software, Inc.
  75. **************************************************************************
  76. "I look back with some satisfaction on what an idiot I was when I was 25,
  77.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  78.