1. 01 Dec, 2004 1 commit
    • Tom Lane's avatar
      Change planner to use the current true disk file size as its estimate of · 5374d097
      Tom Lane authored
      a relation's number of blocks, rather than the possibly-obsolete value
      in pg_class.relpages.  Scale the value in pg_class.reltuples correspondingly
      to arrive at a hopefully more accurate number of rows.  When pg_class
      contains 0/0, estimate a tuple width from the column datatypes and divide
      that into current file size to estimate number of rows.  This improved
      methodology allows us to jettison the ancient hacks that put bogus default
      values into pg_class when a table is first created.  Also, per a suggestion
      from Simon, make VACUUM (but not VACUUM FULL or ANALYZE) adjust the value
      it puts into pg_class.reltuples to try to represent the mean tuple density
      instead of the minimal density that actually prevails just after VACUUM.
      These changes alter the plans selected for certain regression tests, so
      update the expected files accordingly.  (I removed join_1.out because
      it's not clear if it still applies; we can add back any variant versions
      as they are shown to be needed.)
      5374d097
  2. 25 Sep, 2003 1 commit
  3. 07 Aug, 2003 1 commit
  4. 19 Jul, 2003 1 commit
  5. 10 Feb, 2003 1 commit
  6. 25 Jan, 2003 1 commit
    • Tom Lane's avatar
      Allow the planner to collapse explicit inner JOINs together, rather than · 9f5f2124
      Tom Lane authored
      necessarily following the JOIN syntax to develop the query plan.  The old
      behavior is still available by setting GUC variable JOIN_COLLAPSE_LIMIT
      to 1.  Also create a GUC variable FROM_COLLAPSE_LIMIT to control the
      similar decision about when to collapse sub-SELECT lists into their parent
      lists.  (This behavior existed already, but the limit was always
      GEQO_THRESHOLD/2; now it's separately adjustable.)
      9f5f2124
  7. 30 Oct, 2002 2 commits
  8. 28 Oct, 2002 1 commit
  9. 28 Apr, 2002 1 commit
    • Tom Lane's avatar
      Second try at fixing join alias variables. Instead of attaching miscellaneous · 6c598869
      Tom Lane authored
      lists to join RTEs, attach a list of Vars and COALESCE expressions that will
      replace the join's alias variables during planning.  This simplifies
      flatten_join_alias_vars while still making it easy to fix up varno references
      when transforming the query tree.  Add regression test cases for interactions
      of subqueries with outer joins.
      6c598869
  10. 12 Mar, 2002 1 commit
    • Tom Lane's avatar
      Restructure representation of join alias variables. An explicit JOIN · 6eeb95f0
      Tom Lane authored
      now has an RTE of its own, and references to its outputs now are Vars
      referencing the JOIN RTE, rather than CASE-expressions.  This allows
      reverse-listing in ruleutils.c to use the correct alias easily, rather
      than painfully reverse-engineering the alias namespace as it used to do.
      Also, nested FULL JOINs work correctly, because the result of the inner
      joins are simple Vars that the planner can cope with.  This fixes a bug
      reported a couple times now, notably by Tatsuo on 18-Nov-01.  The alias
      Vars are expanded into COALESCE expressions where needed at the very end
      of planning, rather than during parsing.
      Also, beginnings of support for showing plan qualifier expressions in
      EXPLAIN.  There are probably still cases that need work.
      initdb forced due to change of stored-rule representation.
      6eeb95f0
  11. 14 Dec, 2000 1 commit
    • Tom Lane's avatar
      Planner speedup hacking. Avoid saving useless pathkeys, so that path · ea166f11
      Tom Lane authored
      comparison does not consider paths different when they differ only in
      uninteresting aspects of sort order.  (We had a special case of this
      consideration for indexscans already, but generalize it to apply to
      ordered join paths too.)  Be stricter about what is a canonical pathkey
      to allow faster pathkey comparison.  Cache canonical pathkeys and
      dispersion stats for left and right sides of a RestrictInfo's clause,
      to avoid repeated computation.  Total speedup will depend on number of
      tables in a query, but I see about 4x speedup of planning phase for
      a sample seven-table query.
      ea166f11
  12. 06 Nov, 2000 2 commits
  13. 12 Sep, 2000 1 commit
  14. 12 May, 2000 1 commit
  15. 15 Feb, 2000 1 commit
  16. 15 Jan, 2000 1 commit
  17. 09 Jan, 2000 1 commit
  18. 23 Feb, 1999 1 commit