1. 26 Sep, 1999 1 commit
    • Tom Lane's avatar
      Implement constant-expression simplification per Bernard · 40f65241
      Tom Lane authored
      Frankpitt, plus some improvements from yours truly.  The simplifier depends
      on the proiscachable field of pg_proc to tell it whether a function is
      safe to pre-evaluate --- things like nextval() are not, for example.
      Update pg_proc.h to contain reasonable cacheability information; as of
      6.5.* hardly any functions were marked cacheable.  I may have erred too
      far in the other direction; see recent mail to pghackers for more info.
      This update does not force an initdb, exactly, but you won't see much
      benefit from the simplifier until you do one.
      40f65241
  2. 21 Aug, 1999 1 commit
    • Tom Lane's avatar
      Major revision of sort-node handling: push knowledge of query · db436adf
      Tom Lane authored
      sort order down into planner, instead of handling it only at the very top
      level of the planner.  This fixes many things.  An explicit sort is now
      avoided if there is a cheaper alternative (typically an indexscan) not
      only for ORDER BY, but also for the internal sort of GROUP BY.  It works
      even when there is no other reason (such as a WHERE condition) to consider
      the indexscan.  It works for indexes on functions.  It works for indexes
      on functions, backwards.  It's just so cool...
      
      CAUTION: I have changed the representation of SortClause nodes, therefore
      THIS UPDATE BREAKS STORED RULES.  You will need to initdb.
      db436adf
  3. 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
  4. 09 Aug, 1999 1 commit
    • Bruce Momjian's avatar
      > > Prevent sorting if result is already sorted · 158fd5f1
      Bruce Momjian authored
      > >
      > > was implemented by Jan Wieck.
      > > His work is for ascending order cases.
      > >
      > > Here is a patch to prevent sorting also in descending
      > > order cases.
      > > Because I had already changed _bt_first() to position
      > > backward correctly before v6.5,this patch would work.
      > >
      Hiroshi Inoue
      Inoue@tpf.co.jp
      158fd5f1
  5. 29 Jul, 1999 1 commit
  6. 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
  7. 17 Jul, 1999 1 commit
  8. 16 Jul, 1999 1 commit
  9. 15 Jul, 1999 2 commits
  10. 06 Jun, 1999 1 commit
  11. 25 May, 1999 2 commits
  12. 12 May, 1999 1 commit
  13. 18 Feb, 1999 1 commit
  14. 15 Feb, 1999 2 commits
  15. 13 Feb, 1999 1 commit
  16. 12 Feb, 1999 1 commit
  17. 11 Feb, 1999 1 commit
  18. 10 Feb, 1999 2 commits
  19. 09 Feb, 1999 1 commit
  20. 08 Feb, 1999 1 commit
  21. 07 Feb, 1999 1 commit
  22. 06 Feb, 1999 1 commit
  23. 04 Feb, 1999 1 commit
  24. 03 Feb, 1999 1 commit
  25. 02 Feb, 1999 1 commit
  26. 01 Sep, 1998 2 commits
  27. 04 Aug, 1998 1 commit
  28. 01 Aug, 1998 1 commit
  29. 26 Feb, 1998 1 commit
  30. 13 Feb, 1998 1 commit
  31. 10 Feb, 1998 1 commit
  32. 20 Jan, 1998 1 commit
  33. 07 Jan, 1998 1 commit
  34. 05 Jan, 1998 1 commit
  35. 08 Sep, 1997 1 commit