1. 05 8月, 1999 1 次提交
  2. 03 8月, 1999 2 次提交
  3. 02 8月, 1999 6 次提交
  4. 01 8月, 1999 6 次提交
  5. 31 7月, 1999 2 次提交
  6. 30 7月, 1999 9 次提交
  7. 29 7月, 1999 6 次提交
  8. 28 7月, 1999 1 次提交
  9. 27 7月, 1999 4 次提交
    • T
      Correct bug in best_innerjoin(): it should check all the · b62fdc13
      Tom Lane 提交于
      rels that the inner path needs to join to, but it was only checking for
      the first one.  Failure could only have been observed with an OR-clause
      that mentions 3 or more tables, and then only if the bogus path was
      actually selected as cheapest ...
      b62fdc13
    • T
      My recent optimizer changes caused a different plan to · 2f30d5a3
      Tom Lane 提交于
      be picked for one of the complex joins in rules test ... leading to
      a different output ordering ...
      2f30d5a3
    • T
      First cut at doing LIKE/regex indexing optimization in · 9e7e29e6
      Tom Lane 提交于
      optimizer rather than parser.  This has many advantages, such as not
      getting fooled by chance uses of operator names ~ and ~~ (the operators
      are identified by OID now), and not creating useless comparison operations
      in contexts where the comparisons will not actually be used as indexquals.
      The new code also recognizes exact-match LIKE and regex patterns, and
      produces an = indexqual instead of >= and <=.
      
      This change does NOT fix the problem with non-ASCII locales: the code
      still doesn't know how to generate an upper bound indexqual for non-ASCII
      collation order.  But it's no worse than before, just the same deficiency
      in a different place...
      
      Also, dike out loc_restrictinfo fields in Plan nodes.  These were doing
      nothing useful in the absence of 'expensive functions' optimization,
      and they took a considerable amount of processing to fill in.
      9e7e29e6
    • B
      Update TODO list. · 434df3fb
      Bruce Momjian 提交于
      434df3fb
  10. 26 7月, 1999 3 次提交