home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / ingres / 2076 < prev    next >
Encoding:
Text File  |  1992-12-11  |  2.3 KB  |  53 lines

  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!sdd.hp.com!caen!uwm.edu!linac!uchinews!gsbacd.uchicago.edu!cs_mj
  3. From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
  4. Subject: Re: Finding maximum value of a column ?
  5. Message-ID: <1992Dec11.143126.1@gsbacd.uchicago.edu>
  6. Lines: 41
  7. Sender: news@uchinews.uchicago.edu (News System)
  8. Organization:     
  9. References: <1992Dec3.123143.51@ittpub.nl> <1992Dec8.013622.1@gsbacd.uchicago.edu> <1797@niktow.canisius.edu>
  10. Date: Fri, 11 Dec 1992 20:31:26 GMT
  11.  
  12. In article <1797@niktow.canisius.edu>, pavlov@niktow.canisius.edu 
  13. (Greg Pavlov) writes:
  14. > In article <1992Dec8.013622.1@gsbvax.uchicago.edu>, 
  15. > cs_mj@gsbvax.uchicago.edu (Mark Jaeger) writes:
  16. >> 
  17. >> Right, it's slow.  If you look at the QEP, you will see that INGRES uses
  18. >> a secondary index when such use would reduce the i/o's, but even so it
  19. >> always has to do a full scan of either the table or the secondary index
  20. >> in order to find the max.
  21. >> 
  22. >   I do not remember all of the details, but I believe that a key criteria was
  23. >   that if the optimizer believed that more than 1/4 of the total rows needed
  24. >   to be looked at, the base table would be traversed rather than the index
  25. >   first.
  26.  
  27. I don't know all of the details either, but I do know that I've seen the
  28. optimizer behave as I stated.  I discovered it while trying to diagnose
  29. some index corruption problems.  I did this:
  30.  
  31.         select count(tid) from base_table
  32.         union select count(tidp) from index_table
  33.         union select count(i.tidp) from base_table t , index_table ix 
  34.             where t.tid = ix.tidp
  35.  
  36. as suggested by the release notes for some version of 6.3/03.  When I
  37. examined the QEP for this, I discovered to my dismay that INGRES
  38. executed the first query by counting the rows in the smallest secondary
  39. index on the table, rather than going to the base table!  Needless to
  40. say, we had to find another way of diagnosing the corruption problem.
  41.  
  42. Your situation may be different.
  43.  
  44. I'd also like to say that the INGRES optimizer is really good, and
  45. everything I've heard puts it really ahead of the crowd in this field.
  46.  
  47. --Mark Jaeger                internet: cs_mj@gsbvax.uchicago.edu
  48. Graduate School of Business        yellnet:  (312) 702-0328
  49. University of Chicago            faxnet:   (312) 702-0233
  50. Disclaimer: My opinions are my own and not those of my employer.
  51. Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
  52.  
  53.