1. 17 Dec, 2002 1 commit
  2. 12 Dec, 2002 1 commit
    • Tom Lane's avatar
      Phase 2 of read-only-plans project: restructure expression-tree nodes · a0bf885f
      Tom Lane authored
      so that all executable expression nodes inherit from a common supertype
      Expr.  This is somewhat of an exercise in code purity rather than any
      real functional advance, but getting rid of the extra Oper or Func node
      formerly used in each operator or function call should provide at least
      a little space and speed improvement.
      initdb forced by changes in stored-rules representation.
      a0bf885f
  3. 24 Nov, 2002 1 commit
    • Tom Lane's avatar
      Restructure planning of nestloop inner indexscans so that the set of usable · 04c8785c
      Tom Lane authored
      joinclauses is determined accurately for each join.  Formerly, the code only
      considered joinclauses that used all of the rels from the outer side of the
      join; thus for example
      	FROM (a CROSS JOIN b) JOIN c ON (c.f1 = a.x AND c.f2 = b.y)
      could not exploit a two-column index on c(f1,f2), since neither of the
      qual clauses would be in the joininfo list it looked in.  The new code does
      this correctly, and also is able to eliminate redundant clauses, thus fixing
      the problem noted 24-Oct-02 by Hans-Jürgen Schönig.
      04c8785c
  4. 19 Nov, 2002 1 commit
  5. 04 Sep, 2002 1 commit
  6. 02 Sep, 2002 1 commit
  7. 20 Jun, 2002 1 commit
  8. 18 May, 2002 1 commit
    • Tom Lane's avatar
      Change set_plan_references and join_references to take an rtable List · 51fd22ab
      Tom Lane authored
      rather than a Query node; this allows set_plan_references to recurse
      into subplans correctly.  Fixes core dump on full outer joins in
      subplans.  Also, invoke preprocess_expression on function RTEs'
      function expressions.  This seems to fix the planner's problems with
      outer-level Vars in function RTEs.
      51fd22ab
  9. 17 May, 2002 1 commit
  10. 12 May, 2002 1 commit
    • Tom Lane's avatar
      Get rid of long-since-vestigial Iter node type, in favor of adding a · 3389a110
      Tom Lane authored
      returns-set boolean field in Func and Oper nodes.  This allows cleaner,
      more reliable tests for expressions returning sets in the planner and
      parser.  For example, a WHERE clause returning a set is now detected
      and complained of in the parser, not only at runtime.
      3389a110
  11. 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
  12. 16 Apr, 2002 1 commit
    • Tom Lane's avatar
      Operators live in namespaces. CREATE/DROP/COMMENT ON OPERATOR take · 6cef5d25
      Tom Lane authored
      qualified operator names directly, for example CREATE OPERATOR myschema.+
      ( ... ).  To qualify an operator name in an expression you need to write
      OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch).
      I also took advantage of having to reformat pg_operator to fix something
      that'd been bugging me for a while: mergejoinable operators should have
      explicit links to the associated cross-data-type comparison operators,
      rather than hardwiring an assumption that they are named < and >.
      6cef5d25
  13. 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
  14. 01 Mar, 2002 1 commit
  15. 25 Oct, 2001 1 commit
  16. 18 Oct, 2001 1 commit
    • Tom Lane's avatar
      Extend code that deduces implied equality clauses to detect whether a · 6254465d
      Tom Lane authored
      clause being added to a particular restriction-clause list is redundant
      with those already in the list.  This avoids useless work at runtime,
      and (perhaps more importantly) keeps the selectivity estimation routines
      from generating too-small estimates of numbers of output rows.
      Also some minor improvements in OPTIMIZER_DEBUG displays.
      6254465d
  17. 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
  18. 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
  19. 14 May, 2001 1 commit
  20. 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
  21. 16 Apr, 2001 1 commit
    • Tom Lane's avatar
      Avoid reversing user-given order of WHERE clauses while attaching clauses · cdcaec5c
      Tom Lane authored
      to specific base or join RelOptInfo nodes during planning.  This preserves
      the more-intuitive behavior of 7.0.* --- if you write an expensive clause
      (such as a sub-select) last, it should get evaluated last.  Someday we
      ought to try to have some intelligence about the order of evaluation of
      WHERE clauses, but for now we should not override what the user wrote.
      cdcaec5c
  22. 22 Mar, 2001 1 commit
  23. 16 Feb, 2001 1 commit
    • Tom Lane's avatar
      Clean up two rather nasty bugs in operator selection code. · 13cc7eb3
      Tom Lane authored
      1. If there is exactly one pg_operator entry of the right name and oprkind,
      oper() and related routines would return that entry whether its input type
      had anything to do with the request or not.  This is just premature
      optimization: we shouldn't return the single candidate until after we verify
      that it really is a valid candidate, ie, is at least coercion-compatible
      with the given types.
      
      2. oper() and related routines only promise a coercion-compatible result.
      Unfortunately, there were quite a few callers that assumed the returned
      operator is binary-compatible with the given datatype; they would proceed
      to call it without making any datatype coercions.  These callers include
      sorting, grouping, aggregation, and VACUUM ANALYZE.  In general I think
      it is appropriate for these callers to require an exact or binary-compatible
      match, so I've added a new routine compatible_oper() that only succeeds if
      it can find an operator that doesn't require any run-time conversions.
      Callers now call oper() or compatible_oper() depending on whether they are
      prepared to deal with type conversion or not.
      
      The upshot of these bugs is revealed by the following silliness in PL/Tcl's
      selftest: it creates an operator @< on int4, and then tries to use it to
      sort a char(N) column.  The system would let it do that :-( (and evidently
      has done so since 6.3 :-( :-().  The result in this case was just a silly
      sort order, but the reverse combination would've provoked coredump from
      trying to dereference integers.  With this fix you get more reasonable
      behavior:
      pltcl_test=# select * from T_pkey1 order by key1, key2 using @<;
      ERROR:  Unable to identify an operator '@<' for types 'bpchar' and 'bpchar'
              You will have to retype this query using an explicit cast
      13cc7eb3
  24. 24 Jan, 2001 1 commit
  25. 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
  26. 12 Dec, 2000 1 commit
  27. 23 Nov, 2000 1 commit
  28. 16 Nov, 2000 1 commit
  29. 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
  30. 12 Sep, 2000 1 commit
  31. 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
  32. 08 Aug, 2000 1 commit
    • Tom Lane's avatar
      Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist' · 62e29fe2
      Tom Lane authored
      from Param nodes, per discussion a few days ago on pghackers.  Add new
      expression node type FieldSelect that implements the functionality where
      it's actually needed.  Clean up some other unused fields in Func nodes
      as well.
      NOTE: initdb forced due to change in stored expression trees for rules.
      62e29fe2
  33. 24 Jul, 2000 1 commit
    • Tom Lane's avatar
      Deduce equality constraints that are implied by transitivity of · cd9f0ca5
      Tom Lane authored
      mergejoinable qual clauses, and add them to the query quals.  For
      example, WHERE a = b AND b = c will cause us to add AND a = c.
      This is necessary to ensure that it's safe to use these variables
      as interchangeable sort keys, which is something 7.0 knows how to do.
      Should provide a useful improvement in planning ability, too.
      cd9f0ca5
  34. 12 Apr, 2000 1 commit
  35. 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
  36. 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
  37. 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
  38. 22 Jan, 2000 1 commit
  39. 09 Jan, 2000 1 commit
  40. 07 Oct, 1999 1 commit
    • Tom Lane's avatar
      Fix planner and rewriter to follow SQL semantics for tables that are · 3eb1c822
      Tom Lane authored
      mentioned in FROM but not elsewhere in the query: such tables should be
      joined over anyway.  Aside from being more standards-compliant, this allows
      removal of some very ugly hacks for COUNT(*) processing.  Also, allow
      HAVING clause without aggregate functions, since SQL does.  Clean up
      CREATE RULE statement-list syntax the same way Bruce just fixed the
      main stmtmulti production.
      CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
      you will have to initdb if you have any rules.
      3eb1c822