1. 09 May, 2001 2 commits
  2. 07 May, 2001 1 commit
    • Tom Lane's avatar
      Rewrite of planner statistics-gathering code. ANALYZE is now available as · f905d65e
      Tom Lane authored
      a separate statement (though it can still be invoked as part of VACUUM, too).
      pg_statistic redesigned to be more flexible about what statistics are
      stored.  ANALYZE now collects a list of several of the most common values,
      not just one, plus a histogram (not just the min and max values).  Random
      sampling is used to make the process reasonably fast even on very large
      tables.  The number of values and histogram bins collected is now
      user-settable via an ALTER TABLE command.
      
      There is more still to do; the new stats are not being used everywhere
      they could be in the planner.  But the remaining changes for this project
      should be localized, and the behavior is already better than before.
      
      A not-very-related change is that sorting now makes use of btree comparison
      routines if it can find one, rather than invoking '<' twice.
      f905d65e
  3. 25 Apr, 2001 1 commit
  4. 22 Mar, 2001 1 commit
  5. 16 Feb, 2001 1 commit
  6. 15 Feb, 2001 1 commit
  7. 24 Jan, 2001 1 commit
  8. 12 Dec, 2000 1 commit
  9. 05 Oct, 2000 1 commit
  10. 29 Sep, 2000 1 commit
    • Tom Lane's avatar
      Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. · 3a94e789
      Tom Lane authored
      (Don't forget that an alias is required.)  Views reimplemented as expanding
      to subselect-in-FROM.  Grouping, aggregates, DISTINCT in views actually
      work now (he says optimistically).  No UNION support in subselects/views
      yet, but I have some ideas about that.  Rule-related permissions checking
      moved out of rewriter and into executor.
      INITDB REQUIRED!
      3a94e789
  11. 18 Jun, 2000 1 commit
    • Tom Lane's avatar
      Reimplement nodeMaterial to use a temporary BufFile (or even memory, if the · 1ee26b77
      Tom Lane authored
      materialized tupleset is small enough) instead of a temporary relation.
      This was something I was thinking of doing anyway for performance, and Jan
      says he needs it for TOAST because he doesn't want to cope with toasting
      noname relations.  With this change, the 'noname table' support in heap.c
      is dead code, and I have accordingly removed it.  Also clean up 'noname'
      plan handling in planner --- nonames are either sort or materialize plans,
      and it seems less confusing to handle them separately under those names.
      1ee26b77
  12. 31 May, 2000 1 commit
    • Peter Eisentraut's avatar
      The heralded `Grand Unified Configuration scheme' (GUC) · 6a68f426
      Peter Eisentraut authored
      That means you can now set your options in either or all of $PGDATA/configuration,
      some postmaster option (--enable-fsync=off), or set a SET command. The list of
      options is in backend/utils/misc/guc.c, documentation will be written post haste.
      
      pg_options is gone, so is that pq_geqo config file. Also removed were backend -K,
      -Q, and -T options (no longer applicable, although -d0 does the same as -Q).
      
      Added to configure an --enable-syslog option.
      
      changed all callers from TPRINTF to elog(DEBUG)
      6a68f426
  13. 30 May, 2000 2 commits
  14. 18 Apr, 2000 1 commit
  15. 12 Apr, 2000 1 commit
  16. 09 Apr, 2000 1 commit
  17. 30 Mar, 2000 1 commit
  18. 22 Mar, 2000 1 commit
    • Tom Lane's avatar
      Repair logic flaw in cost estimator: cost_nestloop() was estimating CPU · 1d5e7a6f
      Tom Lane authored
      costs using the inner path's parent->rows count as the number of tuples
      processed per inner scan iteration.  This is wrong when we are using an
      inner indexscan with indexquals based on join clauses, because the rows
      count in a Relation node reflects the selectivity of the restriction
      clauses for that rel only.  Upshot was that if join clause was very
      selective, we'd drastically overestimate the true cost of the join.
      Fix is to calculate correct output-rows estimate for an inner indexscan
      when the IndexPath node is created and save it in the path node.
      Change of path node doesn't require initdb, since path nodes don't
      appear in saved rules.
      1d5e7a6f
  19. 14 Mar, 2000 1 commit
  20. 15 Feb, 2000 1 commit
    • Tom Lane's avatar
      New cost model for planning, incorporating a penalty for random page · b1577a7c
      Tom Lane authored
      accesses versus sequential accesses, a (very crude) estimate of the
      effects of caching on random page accesses, and cost to evaluate WHERE-
      clause expressions.  Export critical parameters for this model as SET
      variables.  Also, create SET variables for the planner's enable flags
      (enable_seqscan, enable_indexscan, etc) so that these can be controlled
      more conveniently than via PGOPTIONS.
      
      Planner now estimates both startup cost (cost before retrieving
      first tuple) and total cost of each path, so it can optimize queries
      with LIMIT on a reasonable basis by interpolating between these costs.
      Same facility is a win for EXISTS(...) subqueries and some other cases.
      
      Redesign pathkey representation to achieve a major speedup in planning
      (I saw as much as 5X on a 10-way join); also minor changes in planner
      to reduce memory consumption by recycling discarded Path nodes and
      not constructing unnecessary lists.
      
      Minor cleanups to display more-plausible costs in some cases in
      EXPLAIN output.
      
      Initdb forced by change in interface to index cost estimation
      functions.
      b1577a7c
  21. 07 Feb, 2000 1 commit
    • Tom Lane's avatar
      Repair planning bugs caused by my misguided removal of restrictinfo link · d8733ce6
      Tom Lane authored
      fields in JoinPaths --- turns out that we do need that after all :-(.
      Also, rearrange planner so that only one RelOptInfo is created for a
      particular set of joined base relations, no matter how many different
      subsets of relations it can be created from.  This saves memory and
      processing time compared to the old method of making a bunch of RelOptInfos
      and then removing the duplicates.  Clean up the jointree iteration logic;
      not sure if it's better, but I sure find it more readable and plausible
      now, particularly for the case of 'bushy plans'.
      d8733ce6
  22. 26 Jan, 2000 1 commit
    • Bruce Momjian's avatar
      Add: · 5c25d602
      Bruce Momjian authored
        * Portions Copyright (c) 1996-2000, PostgreSQL, Inc
      
      to all files copyright Regents of Berkeley.  Man, that's a lot of files.
      5c25d602
  23. 23 Jan, 2000 1 commit
  24. 22 Jan, 2000 1 commit
  25. 09 Jan, 2000 1 commit
  26. 23 Nov, 1999 1 commit
  27. 22 Aug, 1999 1 commit
    • Tom Lane's avatar
      Further planner/optimizer cleanups. Move all set_tlist_references · 78114cd4
      Tom Lane authored
      and fix_opids processing to a single recursive pass over the plan tree
      executed at the very tail end of planning, rather than haphazardly here
      and there at different places.  Now that tlist Vars do not get modified
      until the very end, it's possible to get rid of the klugy var_equal and
      match_varid partial-matching routines, and just use plain equal()
      throughout the optimizer.  This is a step towards allowing merge and
      hash joins to be done on expressions instead of only Vars ...
      78114cd4
  28. 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
  29. 16 Jul, 1999 1 commit
  30. 15 Jul, 1999 1 commit
  31. 07 Jul, 1999 3 commits
  32. 25 May, 1999 2 commits
  33. 01 May, 1999 1 commit
  34. 30 Apr, 1999 1 commit
  35. 05 Apr, 1999 1 commit