1. 22 Jan, 2000 1 commit
  2. 09 Jan, 2000 1 commit
  3. 23 Nov, 1999 1 commit
  4. 16 Aug, 1999 1 commit
    • Tom Lane's avatar
      Major planner/optimizer revision: get rid of PathOrder node type, · e6381966
      Tom Lane authored
      store all ordering information in pathkeys lists (which are now lists of
      lists of PathKeyItem nodes, not just lists of lists of vars).  This was
      a big win --- the code is smaller and IMHO more understandable than it
      was, even though it handles more cases.  I believe the node changes will
      not force an initdb for anyone; planner nodes don't show up in stored
      rules.
      e6381966
  5. 06 Aug, 1999 1 commit
    • Tom Lane's avatar
      Revise generation of hashjoin paths: generate one path per · e1fad50a
      Tom Lane authored
      hashjoinable clause, not one path for a randomly-chosen element of each
      set of clauses with the same join operator.  That is, if you wrote
         SELECT ... WHERE t1.f1 = t2.f2 and t1.f3 = t2.f4,
      and both '=' ops were the same opcode (say, all four fields are int4),
      then the system would either consider hashing on f1=f2 or on f3=f4,
      but it would *not* consider both possibilities.  Boo hiss.
      Also, revise estimation of hashjoin costs to include a penalty when the
      inner join var has a high disbursion --- ie, the most common value is
      pretty common.  This tends to lead to badly skewed hash bucket occupancy
      and way more comparisons than you'd expect on average.
      I imagine that the cost calculation still needs tweaking, but at least
      it generates a more reasonable plan than before on George Young's example.
      e1fad50a
  6. 30 Jul, 1999 3 commits
  7. 27 Jul, 1999 1 commit
    • Tom Lane's avatar
      First cut at doing LIKE/regex indexing optimization in · 9e7e29e6
      Tom Lane authored
      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
  8. 25 Jul, 1999 1 commit
  9. 24 Jul, 1999 1 commit
    • Tom Lane's avatar
      Clean up messy clause-selectivity code in clausesel.c; repair bug · ac4913a0
      Tom Lane authored
      identified by Hiroshi (incorrect cost attributed to OR clauses
      after multiple passes through set_rest_selec()).  I think the code
      was trying to allow selectivities of OR subclauses to be passed in
      from outside, but noplace was actually passing any useful data, and
      set_rest_selec() was passing wrong data.
      
      Restructure representation of "indexqual" in IndexPath nodes so that
      it is the same as for indxqual in completed IndexScan nodes: namely,
      a toplevel list with an entry for each pass of the index scan, having
      sublists that are implicitly-ANDed index qual conditions for that pass.
      You don't want to know what the old representation was :-(
      
      Improve documentation of OR-clause indexscan functions.
      
      Remove useless 'notclause' field from RestrictInfo nodes.  (This might
      force an initdb for anyone who has stored rules containing RestrictInfos,
      but I do not think that RestrictInfo ever appears in completed plans.)
      ac4913a0
  10. 16 Jul, 1999 2 commits
  11. 15 Jul, 1999 2 commits
  12. 25 May, 1999 2 commits
  13. 21 Feb, 1999 1 commit
    • Marc G. Fournier's avatar
      · 8c3e8a8a
      Marc G. Fournier authored
      From: Tatsuo Ishii <t-ishii@sra.co.jp>
      
      Ok. I made patches replacing all of "#if FALSE" or "#if 0" to "#ifdef
      NOT_USED" for current. I have tested these patches in that the
      postgres binaries are identical.
      8c3e8a8a
  14. 20 Feb, 1999 2 commits
  15. 18 Feb, 1999 1 commit
  16. 15 Feb, 1999 1 commit
  17. 13 Feb, 1999 1 commit
  18. 12 Feb, 1999 3 commits
  19. 11 Feb, 1999 8 commits
  20. 10 Feb, 1999 2 commits
  21. 09 Feb, 1999 1 commit
  22. 08 Feb, 1999 1 commit
  23. 06 Feb, 1999 1 commit
  24. 04 Feb, 1999 1 commit