home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / informix / 2907 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.5 KB
  1. Path: sparky!uunet!thehulk!admnews!lebrun
  2. Newsgroups: comp.databases.informix
  3. Subject: Find Next row - Performance questions
  4. Message-ID: <1993Jan8.171055.21198@admins.com>
  5. From: lebrun@admins.com (John LeBrun)
  6. Date: Fri, 8 Jan 1993 17:10:55 GMT
  7. Organization: Admins, Inc.
  8. Lines: 92
  9.  
  10.  
  11.     I am in the process of porting our 4GL Development Product to
  12. INFORMIX, our first port to a Standard SQL RDBMS.  Since our current
  13. file system uses a variation of the standard index file method.  I
  14. have found it difficult to support all of our existing operations, and
  15. provide reasonable performance.
  16.  
  17.     The largest performance problem occurs when executing a
  18. logical next/prev record request.  (To explain: a logical next record,
  19. given a key of N columns and a value, find the next record in key
  20. order) I currently have an implementation that is flexible enough to
  21. return the correct request for any table or key.  I am looking for
  22. comments and suggestions on ways to improve performance.
  23.  
  24.  
  25. Algorithm:
  26.  
  27.     Next record is the minimum value of key for all rows
  28. with key values greater than the current value of key.
  29.  
  30.     For a key of one column:
  31.  
  32.     select min(lname) from maillist where lname > 'lebrun'
  33.  
  34.  
  35.     However; in a real application the key is usually multiple
  36. columns.
  37.  
  38.     For a key of two columns:
  39.  
  40.     select lname, fname from maillist where lname = 'LeBrun' 
  41.         and fname = (select min(fname) from maillist 
  42.                              where lname = 'LeBrun' and fname > 'John')
  43.  
  44.         select lname,fname from maillist  
  45.             where lname = (select min(lname) from maillist 
  46.                                where lname > 'LeBrun') 
  47.                and fname = (select min(fname) from maillist 
  48.            where lname = (select min(lname) from maillist 
  49.                       where lname > 'LeBrun'))
  50.  
  51.  
  52.     In the above, lname is the primary column and fname is
  53. secondary column of the key.  This example also assumes that
  54. (lname,fname) is a unique key, otherwise a third column "rowid" would
  55. be needed to determine uniqueness.  For each column in key there is a need to
  56. select for each possible break level.  With the possibility of up to 9
  57. columns in a key, this method can get very costly.
  58.  
  59.     On way to increase the performance of the above query is to OR
  60. each break level query together and add an ORDER BY statement.  The
  61. first record in the requesting table is the correct one, however; the
  62. rest of the resulting table would not necessary be of value.  If all
  63. the break level queries are OR'ed together, would the string exceed
  64. the INFORMIX buffer size?  Or any other INFORMIX limits?
  65.  
  66.     In the above example would INFORMIX buffer the information
  67. from each sub-query?  Should I (is it possible) to remove the
  68. sub-queries?  
  69.  
  70.     How many and on which columns should indexes be placed?
  71.  
  72.     create unique index on lname,fname
  73.  
  74.     OR
  75.  
  76.     create unique index on lname,fname
  77.     create index on lname
  78.     create index on fname
  79.  
  80.     OR
  81.  
  82.     ???
  83.     
  84.  
  85.     What if I generate a query which selects all records greater
  86. than the current one, ORDER BY 'key'.  Will INFORMIX determine that a
  87. sort is not necessary?  What about this approach, if the table is very
  88. large millions of rows?
  89.  
  90.     I have also needed to implement pervious, first and last.
  91. Thank you for reading this posting.  If you can provide any
  92. assistance, please respond either by e-mail or post.  I will post a
  93. summary of answers, if such can be done with this type of question.
  94.  
  95.  
  96.  
  97. --
  98. John LeBrun                           lebrun@admins.com
  99. Admins, Inc.                          (617) 494-5100
  100. 432 Columbia Ave.                     "Providing 4GL development tools
  101. Cambridge, MA                                since 1972"
  102.