1. 19 Jun, 1999 1 commit
  2. 25 May, 1999 2 commits
  3. 10 May, 1999 1 commit
  4. 01 Mar, 1999 1 commit
    • Tom Lane's avatar
      Executor no longer cares about mergejoinop, mergerightorder, mergeleftorder, · b204d10c
      Tom Lane authored
      so remove them from MergeJoin node.  Hack together a partial
      solution for commuted mergejoin operators --- yesterday
      a mergejoin int4 = int8 would crash if the planner decided to
      commute it, today it works.  The planner's representation of
      mergejoins really needs a rewrite though.
      Also, further testing of mergejoin ops in opr_sanity regress test.
      b204d10c
  5. 18 Feb, 1999 1 commit
  6. 14 Feb, 1999 1 commit
  7. 13 Feb, 1999 1 commit
  8. 03 Feb, 1999 1 commit
  9. 24 Jan, 1999 1 commit
  10. 04 Dec, 1998 1 commit
  11. 27 Nov, 1998 1 commit
  12. 01 Sep, 1998 2 commits
  13. 31 Aug, 1998 2 commits
  14. 10 Aug, 1998 1 commit
  15. 09 Aug, 1998 1 commit
  16. 07 Aug, 1998 1 commit
  17. 15 Jun, 1998 1 commit
  18. 26 Feb, 1998 1 commit
  19. 13 Feb, 1998 1 commit
  20. 20 Jan, 1998 1 commit
  21. 22 Dec, 1997 1 commit
  22. 25 Sep, 1997 1 commit
  23. 08 Sep, 1997 3 commits
  24. 07 Sep, 1997 1 commit
  25. 19 Aug, 1997 1 commit
  26. 22 Jan, 1997 1 commit
  27. 30 Nov, 1996 1 commit
  28. 06 Nov, 1996 1 commit
  29. 10 Sep, 1996 1 commit
    • Marc G. Fournier's avatar
      Fixes: · 796f7899
      Marc G. Fournier authored
      The problem is that the function arguments are not considered as possible key
      candidates for index scan and so only a sequential scan is possible inside
      the body of a function.  I have therefore made some patches to the optimizer
      so that indices are now used also by functions.  I have also moved the plan
      debug message from pg_eval to pg_plan so that it is printed also for plans
      genereated for function execution.  I had also to add an index rescan to the
      executor because it ignored the parameters set in the execution state, they
      were flagged as runtime variables in ExecInitIndexScan but then never used
      by the executor so that the scan were always done with any key=1. Very odd.
      This means that an index rescan is now done twice for each function execution
      which uses an index, the first time when the index scan is initialized and
      the second when the actual function arguments are finally available for the
      execution.  I don't know what is the cost of an double index scan but I
      suppose it is anyway less than the cost of a full sequential scan, at leat
      for large tables. This is my patch, you must also add -DINDEXSCAN_PATCH in
      Makefile.global to enable the changes.
      
      Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
      796f7899
  30. 25 Jul, 1996 1 commit
  31. 09 Jul, 1996 1 commit