1. 19 Sep, 2006 1 commit
    • Tom Lane's avatar
      Improve usage of effective_cache_size parameter by assuming that all the · b74c5436
      Tom Lane authored
      tables in the query compete for cache space, not just the one we are
      currently costing an indexscan for.  This seems more realistic, and it
      definitely will help in examples recently exhibited by Stefan
      Kaltenbrunner.  To get the total size of all the tables involved, we must
      tweak the handling of 'append relations' a bit --- formerly we looked up
      information about the child tables on-the-fly during set_append_rel_pathlist,
      but it needs to be done before we start doing any cost estimation, so
      push it into the add_base_rels_to_query scan.
      b74c5436
  2. 14 Jul, 2006 1 commit
  3. 01 Jul, 2006 1 commit
    • Tom Lane's avatar
      Revise the planner's handling of "pseudoconstant" WHERE clauses, that is · cffd89ca
      Tom Lane authored
      clauses containing no variables and no volatile functions.  Such a clause
      can be used as a one-time qual in a gating Result plan node, to suppress
      plan execution entirely when it is false.  Even when the clause is true,
      putting it in a gating node wins by avoiding repeated evaluation of the
      clause.  In previous PG releases, query_planner() would do this for
      pseudoconstant clauses appearing at the top level of the jointree, but
      there was no ability to generate a gating Result deeper in the plan tree.
      To fix it, get rid of the special case in query_planner(), and instead
      process pseudoconstant clauses through the normal RestrictInfo qual
      distribution mechanism.  When a pseudoconstant clause is found attached to
      a path node in create_plan(), pull it out and generate a gating Result at
      that point.  This requires special-casing pseudoconstants in selectivity
      estimation and cost_qual_eval, but on the whole it's pretty clean.
      It probably even makes the planner a bit faster than before for the normal
      case of no pseudoconstants, since removing pull_constant_clauses saves one
      useless traversal of the qual tree.  Per gripe from Phil Frost.
      cffd89ca
  4. 05 Mar, 2006 1 commit
  5. 31 Jan, 2006 1 commit
    • Tom Lane's avatar
      Restructure planner's handling of inheritance. Rather than processing · 8a1468af
      Tom Lane authored
      inheritance trees on-the-fly, which pretty well constrained us to considering
      only one way of planning inheritance, expand inheritance sets during the
      planner prep phase, and build a side data structure that can be consulted
      later to find which RTEs are members of which inheritance sets.  As proof of
      concept, use the data structure to plan joins against inheritance sets more
      efficiently: we can now use indexes on the set members in inner-indexscan
      joins.  (The generated plans could be improved further, but it'll take some
      executor changes.)  This data structure will also support handling UNION ALL
      subqueries in the same way as inheritance sets, but that aspect of it isn't
      finished yet.
      8a1468af
  6. 20 Dec, 2005 1 commit
  7. 22 Nov, 2005 1 commit
  8. 15 Oct, 2005 1 commit
  9. 28 Sep, 2005 1 commit
  10. 27 Aug, 2005 1 commit
    • Tom Lane's avatar
      Change the division of labor between grouping_planner and query_planner · 4e5fbb34
      Tom Lane authored
      so that the latter estimates the number of groups that grouping will
      produce.  This is needed because it is primarily query_planner that
      makes the decision between fast-start and fast-finish plans, and in the
      original coding it was unable to make more than a crude rule-of-thumb
      choice when the query involved grouping.  This revision helps us make
      saner choices for queries like SELECT ... GROUP BY ... LIMIT, as in a
      recent example from Mark Kirkwood.  Also move the responsibility for
      canonicalizing sort_pathkeys and group_pathkeys into query_planner;
      this information has to be available anyway to support the first change,
      and doing it this way lets us get rid of compare_noncanonical_pathkeys
      entirely.
      4e5fbb34
  11. 02 Jul, 2005 1 commit
    • Tom Lane's avatar
      Teach planner about some cases where a restriction clause can be · cc5e80b8
      Tom Lane authored
      propagated inside an outer join.  In particular, given
      LEFT JOIN ON (A = B) WHERE A = constant, we cannot conclude that
      B = constant at the top level (B might be null instead), but we
      can nonetheless put a restriction B = constant into the quals for
      B's relation, since no inner-side rows not meeting that condition
      can contribute to the final result.  Similarly, given
      FULL JOIN USING (J) WHERE J = constant, we can't directly conclude
      that either input J variable = constant, but it's OK to push such
      quals into each input rel.  Per recent gripe from Kim Bisgaard.
      Along the way, remove 'valid_everywhere' flag from RestrictInfo,
      as on closer analysis it was not being used for anything, and was
      defined backwards anyway.
      cc5e80b8
  12. 10 Jun, 2005 1 commit
    • Tom Lane's avatar
      Quick hack to allow the outer query's tuple_fraction to be passed down · a87ee007
      Tom Lane authored
      to a subquery if the outer query is simple enough that the LIMIT can
      be reflected directly to the subquery.  This didn't use to be very
      interesting, because a subquery that couldn't have been flattened into
      the upper query was usually not going to be very responsive to
      tuple_fraction anyway.  But with new code that allows UNION ALL subqueries
      to pay attention to tuple_fraction, this is useful to do.  In particular
      this lets the optimization occur when the UNION ALL is directly inside
      a view.
      a87ee007
  13. 08 Jun, 2005 1 commit
  14. 06 Jun, 2005 1 commit
    • Tom Lane's avatar
      Nab some low-hanging fruit: replace the planner's base_rel_list and · 9a586fe0
      Tom Lane authored
      other_rel_list with a single array indexed by rangetable index.
      This reduces find_base_rel from O(N) to O(1) without any real penalty.
      While find_base_rel isn't one of the major bottlenecks in any profile
      I've seen so far, it was starting to creep up on the radar screen
      for complex queries --- so might as well fix it.
      9a586fe0
  15. 05 Jun, 2005 1 commit
    • Tom Lane's avatar
      Remove planner's private fields from Query struct, and put them into · 9ab4d981
      Tom Lane authored
      a new PlannerInfo struct, which is passed around instead of the bare
      Query in all the planning code.  This commit is essentially just a
      code-beautification exercise, but it does open the door to making
      larger changes to the planner data structures without having to muck
      with the widely-known Query struct.
      9ab4d981
  16. 31 Dec, 2004 1 commit
    • PostgreSQL Daemon's avatar
      · 2ff50159
      PostgreSQL Daemon authored
      Tag appropriate files for rc3
      
      Also performed an initial run through of upgrading our Copyright date to
      extend to 2005 ... first run here was very simple ... change everything
      where: grep 1996-2004 && the word 'Copyright' ... scanned through the
      generated list with 'less' first, and after, to make sure that I only
      picked up the right entries ...
      2ff50159
  17. 29 Aug, 2004 1 commit
  18. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  19. 04 Aug, 2003 2 commits
  20. 25 Jul, 2003 1 commit
  21. 10 Mar, 2003 1 commit
    • Tom Lane's avatar
      Restructure parsetree representation of DECLARE CURSOR: now it's a · aa83bc04
      Tom Lane authored
      utility statement (DeclareCursorStmt) with a SELECT query dangling from
      it, rather than a SELECT query with a few unusual fields in it.  Add
      code to determine whether a planned query can safely be run backwards.
      If DECLARE CURSOR specifies SCROLL, ensure that the plan can be run
      backwards by adding a Materialize plan node if it can't.  Without SCROLL,
      you get an error if you try to fetch backwards from a cursor that can't
      handle it.  (There is still some discussion about what the exact
      behavior should be, but this is necessary infrastructure in any case.)
      Along the way, make EXPLAIN DECLARE CURSOR work.
      aa83bc04
  22. 20 Jan, 2003 1 commit
    • Tom Lane's avatar
      IN clauses appearing at top level of WHERE can now be handled as joins. · bdfbfde1
      Tom Lane authored
      There are two implementation techniques: the executor understands a new
      JOIN_IN jointype, which emits at most one matching row per left-hand row,
      or the result of the IN's sub-select can be fed through a DISTINCT filter
      and then joined as an ordinary relation.
      Along the way, some minor code cleanup in the optimizer; notably, break
      out most of the jointree-rearrangement preprocessing in planner.c and
      put it in a new file prep/prepjointree.c.
      bdfbfde1
  23. 15 Jan, 2003 1 commit
    • Tom Lane's avatar
      Allow merge and hash joins to occur on arbitrary expressions (anything not · de97072e
      Tom Lane authored
      containing a volatile function), rather than only on 'Var = Var' clauses
      as before.  This makes it practical to do flatten_join_alias_vars at the
      start of planning, which in turn eliminates a bunch of klugery inside the
      planner to deal with alias vars.  As a free side effect, we now detect
      implied equality of non-Var expressions; for example in
      	SELECT ... WHERE a.x = b.y and b.y = 42
      we will deduce a.x = 42 and use that as a restriction qual on a.  Also,
      we can remove the restriction introduced 12/5/02 to prevent pullup of
      subqueries whose targetlists contain sublinks.
      Still TODO: make statistical estimation routines in selfuncs.c and costsize.c
      smarter about expressions that are more complex than plain Vars.  The need
      for this is considerably greater now that we have to be able to estimate
      the suitability of merge and hash join techniques on such expressions.
      de97072e
  24. 21 Nov, 2002 1 commit
  25. 06 Nov, 2002 1 commit
    • Tom Lane's avatar
      First phase of implementing hash-based grouping/aggregation. An AGG plan · f6dba10e
      Tom Lane authored
      node now does its own grouping of the input rows, and has no need for a
      preceding GROUP node in the plan pipeline.  This allows elimination of
      the misnamed tuplePerGroup option for GROUP, and actually saves more code
      in nodeGroup.c than it costs in nodeAgg.c, as well as being presumably
      faster.  Restructure the API of query_planner so that we do not commit to
      using a sorted or unsorted plan in query_planner; instead grouping_planner
      makes the decision.  (Right now it isn't any smarter than query_planner
      was, but that will change as soon as it has the option to select a hash-
      based aggregation step.)  Despite all the hackery, no initdb needed since
      only in-memory node types changed.
      f6dba10e
  26. 02 Sep, 2002 1 commit
  27. 20 Jun, 2002 1 commit
  28. 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
  29. 25 Oct, 2001 1 commit
  30. 05 Jun, 2001 1 commit
    • Tom Lane's avatar
      Further work on making use of new statistics in planner. Adjust APIs · 7c579fa1
      Tom Lane authored
      of costsize.c routines to pass Query root, so that costsize can figure
      more things out by itself and not be so dependent on its callers to tell
      it everything it needs to know.  Use selectivity of hash or merge clause
      to estimate number of tuples processed internally in these joins
      (this is more useful than it would've been before, since eqjoinsel is
      somewhat more accurate than before).
      7c579fa1
  31. 20 May, 2001 1 commit
    • Tom Lane's avatar
      Modify optimizer data structures so that IndexOptInfo lists built for · be03eb25
      Tom Lane authored
      create_index_paths are not immediately discarded, but are available for
      subsequent planner work.  This allows avoiding redundant syscache lookups
      in several places.  Change interface to operator selectivity estimation
      procedures to allow faster and more flexible estimation.
      Initdb forced due to change of pg_proc entries for selectivity functions!
      be03eb25
  32. 22 Mar, 2001 1 commit
  33. 24 Jan, 2001 1 commit
  34. 12 Nov, 2000 1 commit
    • Tom Lane's avatar
      Restructure handling of inheritance queries so that they work with outer · 6543d81d
      Tom Lane authored
      joins, and clean things up a good deal at the same time.  Append plan node
      no longer hacks on rangetable at runtime --- instead, all child tables are
      given their own RT entries during planning.  Concept of multiple target
      tables pushed up into execMain, replacing bug-prone implementation within
      nodeAppend.  Planner now supports generating Append plans for inheritance
      sets either at the top of the plan (the old way) or at the bottom.  Expanding
      at the bottom is appropriate for tables used as sources, since they may
      appear inside an outer join; but we must still expand at the top when the
      target of an UPDATE or DELETE is an inheritance set, because we actually need
      a different targetlist and junkfilter for each target table in that case.
      Fortunately a target table can't be inside an outer join...  Bizarre mutual
      recursion between union_planner and prepunion.c is gone --- in fact,
      union_planner doesn't really have much to do with union queries anymore,
      so I renamed it grouping_planner.
      6543d81d
  35. 05 Oct, 2000 1 commit
    • Tom Lane's avatar
      Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the · 05e3d0ee
      Tom Lane authored
      SQL92 semantics, including support for ALL option.  All three can be used
      in subqueries and views.  DISTINCT and ORDER BY work now in views, too.
      This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT
      where the SELECT yields different datatypes than the INSERT needs.  I did
      that by making UNION subqueries and SELECT in INSERT be treated like
      subselects-in-FROM, thereby allowing an extra level of targetlist where the
      datatype conversions can be inserted safely.
      INITDB NEEDED!
      05e3d0ee
  36. 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
  37. 12 Sep, 2000 1 commit
  38. 13 Aug, 2000 1 commit
    • Tom Lane's avatar
      Clean up handling of variable-free qual clauses. System now does the · 37168b8d
      Tom Lane authored
      right thing with variable-free clauses that contain noncachable functions,
      such as 'WHERE random() < 0.5' --- these are evaluated once per
      potential output tuple.  Expressions that contain only Params are
      now candidates to be indexscan quals --- for example, 'var = ($1 + 1)'
      can now be indexed.  Cope with RelabelType nodes atop potential indexscan
      variables --- this oversight prevents 7.0.* from recognizing some
      potentially indexscanable situations.
      37168b8d
  39. 27 Jul, 2000 1 commit