1. 16 Dec, 2002 1 commit
    • Tom Lane's avatar
      Fix GEQO to work again in CVS tip, by being more careful about memory · 9f76d0d9
      Tom Lane authored
      allocation in best_inner_indexscan().  While at it, simplify GEQO's
      interface to the main planner --- make_join_rel() offers exactly the
      API it really wants, whereas calling make_rels_by_clause_joins() and
      make_rels_by_clauseless_joins() required jumping through hoops.
      Rewrite gimme_tree for clarity (sometimes iteration is much better than
      recursion), and approximately halve GEQO's runtime by recognizing that
      tours of the forms (a,b,c,d,...) and (b,a,c,d,...) are equivalent
      because of symmetry in make_join_rel().
      9f76d0d9
  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. 20 Jun, 2002 1 commit
  5. 05 Nov, 2001 1 commit
  6. 28 Oct, 2001 1 commit
  7. 25 Oct, 2001 1 commit
  8. 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
  9. 21 Aug, 2001 1 commit
    • Tom Lane's avatar
      Restructure pg_opclass, pg_amop, and pg_amproc per previous discussions in · f933766b
      Tom Lane authored
      pgsql-hackers.  pg_opclass now has a row for each opclass supported by each
      index AM, not a row for each opclass name.  This allows pg_opclass to show
      directly whether an AM supports an opclass, and furthermore makes it possible
      to store additional information about an opclass that might be AM-dependent.
      pg_opclass and pg_amop now store "lossy" and "haskeytype" information that we
      previously expected the user to remember to provide in CREATE INDEX commands.
      Lossiness is no longer an index-level property, but is associated with the
      use of a particular operator in a particular index opclass.
      
      Along the way, IndexSupportInitialize now uses the syscaches to retrieve
      pg_amop and pg_amproc entries.  I find this reduces backend launch time by
      about ten percent, at the cost of a couple more special cases in catcache.c's
      IndexScanOK.
      
      Initial work by Oleg Bartunov and Teodor Sigaev, further hacking by Tom Lane.
      
      initdb forced.
      f933766b
  10. 05 Jun, 2001 1 commit
    • Tom Lane's avatar
      Improve planning of OR indexscan plans: for quals like · cdd230d6
      Tom Lane authored
      	WHERE (a = 1 or a = 2) and b = 42
      and an index on (a,b), include the clause b = 42 in the indexquals
      generated for each arm of the OR clause.  Essentially this is an index-
      driven conversion from CNF to DNF.  Implementation is a bit klugy, but
      better than not exploiting the extra quals at all ...
      cdd230d6
  11. 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
  12. 22 Mar, 2001 1 commit
  13. 24 Jan, 2001 2 commits
  14. 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
  15. 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
  16. 12 Sep, 2000 1 commit
  17. 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
  18. 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
  19. 12 Apr, 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. 06 Feb, 2000 1 commit
  23. 05 Feb, 2000 1 commit
  24. 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
  25. 22 Jan, 2000 1 commit
  26. 09 Jan, 2000 1 commit
  27. 23 Nov, 1999 1 commit
  28. 21 Aug, 1999 1 commit
    • Tom Lane's avatar
      Major revision of sort-node handling: push knowledge of query · db436adf
      Tom Lane authored
      sort order down into planner, instead of handling it only at the very top
      level of the planner.  This fixes many things.  An explicit sort is now
      avoided if there is a cheaper alternative (typically an indexscan) not
      only for ORDER BY, but also for the internal sort of GROUP BY.  It works
      even when there is no other reason (such as a WHERE condition) to consider
      the indexscan.  It works for indexes on functions.  It works for indexes
      on functions, backwards.  It's just so cool...
      
      CAUTION: I have changed the representation of SortClause nodes, therefore
      THIS UPDATE BREAKS STORED RULES.  You will need to initdb.
      db436adf
  29. 16 Aug, 1999 1 commit
    • Tom Lane's avatar
      Major planner/optimizer revision: get rid of PathOrder node type, · e6381966
      Tom Lane authored
      store all ordering information in pathkeys lists (which are now lists of
      lists of PathKeyItem nodes, not just lists of lists of vars).  This was
      a big win --- the code is smaller and IMHO more understandable than it
      was, even though it handles more cases.  I believe the node changes will
      not force an initdb for anyone; planner nodes don't show up in stored
      rules.
      e6381966
  30. 27 Jul, 1999 2 commits
    • Tom Lane's avatar
      Correct bug in best_innerjoin(): it should check all the · b62fdc13
      Tom Lane authored
      rels that the inner path needs to join to, but it was only checking for
      the first one.  Failure could only have been observed with an OR-clause
      that mentions 3 or more tables, and then only if the bogus path was
      actually selected as cheapest ...
      b62fdc13
    • Tom Lane's avatar
      First cut at doing LIKE/regex indexing optimization in · 9e7e29e6
      Tom Lane authored
      optimizer rather than parser.  This has many advantages, such as not
      getting fooled by chance uses of operator names ~ and ~~ (the operators
      are identified by OID now), and not creating useless comparison operations
      in contexts where the comparisons will not actually be used as indexquals.
      The new code also recognizes exact-match LIKE and regex patterns, and
      produces an = indexqual instead of >= and <=.
      
      This change does NOT fix the problem with non-ASCII locales: the code
      still doesn't know how to generate an upper bound indexqual for non-ASCII
      collation order.  But it's no worse than before, just the same deficiency
      in a different place...
      
      Also, dike out loc_restrictinfo fields in Plan nodes.  These were doing
      nothing useful in the absence of 'expensive functions' optimization,
      and they took a considerable amount of processing to fill in.
      9e7e29e6
  31. 15 Jul, 1999 1 commit
  32. 26 May, 1999 1 commit
  33. 25 May, 1999 2 commits
  34. 03 Apr, 1999 1 commit
  35. 22 Feb, 1999 1 commit
  36. 21 Feb, 1999 1 commit
  37. 19 Feb, 1999 1 commit