1. 01 Mar, 2005 1 commit
  2. 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
  3. 11 Oct, 2004 1 commit
    • Tom Lane's avatar
      Fix OR-index-scan planner to recognize that a partial index is usable · 26112850
      Tom Lane authored
      for scanning one term of an OR clause if the index's predicate is implied
      by that same OR clause term (possibly in conjunction with top-level WHERE
      clauses).  Per recent example from Dawid Kuroczko,
      http://archives.postgresql.org/pgsql-performance/2004-10/msg00095.php
      Also, fix a very long-standing bug in index predicate testing, namely the
      bizarre ordering of decomposition of predicate and restriction clauses.
      AFAICS the correct way is to break down the predicate all the way, and
      then for each component term see if you can prove it from the entire
      restriction set.  The original coding had a purely-implementation-artifact
      distinction between ANDing at the top level and ANDing below that, and
      proceeded to get the decomposition order wrong everywhere below the top
      level, with the result that even slightly complicated AND/OR predicates
      could not be proven.  For instance, given
      create index foop on foo(f2) where f1=42 or f1=1
          or (f1 = 11 and f2 = 55);
      the old code would fail to match this index to the query
      select * from foo where f1 = 11 and f2 = 55;
      when it obviously ought to match.
      26112850
  4. 29 Aug, 2004 2 commits
  5. 01 Jun, 2004 1 commit
  6. 30 May, 2004 1 commit
  7. 26 May, 2004 1 commit
    • Neil Conway's avatar
      Reimplement the linked list data structure used throughout the backend. · d0b4399d
      Neil Conway authored
      In the past, we used a 'Lispy' linked list implementation: a "list" was
      merely a pointer to the head node of the list. The problem with that
      design is that it makes lappend() and length() linear time. This patch
      fixes that problem (and others) by maintaining a count of the list
      length and a pointer to the tail node along with each head node pointer.
      A "list" is now a pointer to a structure containing some meta-data
      about the list; the head and tail pointers in that structure refer
      to ListCell structures that maintain the actual linked list of nodes.
      
      The function names of the list API have also been changed to, I hope,
      be more logically consistent. By default, the old function names are
      still available; they will be disabled-by-default once the rest of
      the tree has been updated to use the new API names.
      d0b4399d
  8. 05 Jan, 2004 2 commits
    • Tom Lane's avatar
      Adjust indexscan planning logic to keep RestrictInfo nodes associated · fa559a86
      Tom Lane authored
      with index qual clauses in the Path representation.  This saves a little
      work during createplan and (probably more importantly) allows reuse of
      cached selectivity estimates during indexscan planning.  Also fix latent
      bug: wrong plan would have been generated for a 'special operator' used
      in a nestloop-inner-indexscan join qual, because the special operator
      would not have gotten into the list of quals to recheck.  This bug is
      only latent because at present the special-operator code could never
      trigger on a join qual, but sooner or later someone will want to do it.
      fa559a86
    • Tom Lane's avatar
      Add the ability to extract OR indexscan conditions from OR-of-AND · 9091e8d1
      Tom Lane authored
      join conditions in which each OR subclause includes a constraint on
      the same relation.  This implements the other useful side-effect of
      conversion to CNF format, without its unpleasant side-effects.  As
      per pghackers discussion of a few weeks ago.
      9091e8d1
  9. 04 Jan, 2004 1 commit
    • Tom Lane's avatar
      Rewrite OR indexscan processing to be more flexible. We can now for the · 6cb1c023
      Tom Lane authored
      first time generate an OR indexscan for a two-column index when the WHERE
      condition is like 'col1 = foo AND (col2 = bar OR col2 = baz)' --- before,
      the OR had to be on the first column of the index or we'd not notice the
      possibility of using it.  Some progress towards extracting OR indexscans
      from subclauses of an OR that references multiple relations, too, although
      this code is #ifdef'd out because it needs more work.
      6cb1c023
  10. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  11. 04 Aug, 2003 2 commits
  12. 15 Jun, 2003 1 commit
  13. 28 May, 2003 1 commit
  14. 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
  15. 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
  16. 20 Jun, 2002 1 commit
  17. 28 Oct, 2001 1 commit
  18. 25 Oct, 2001 1 commit
  19. 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
  20. 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
  21. 24 Jan, 2001 1 commit
  22. 12 Sep, 2000 1 commit
  23. 30 May, 2000 1 commit
  24. 12 Apr, 2000 1 commit
  25. 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
  26. 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
  27. 05 Feb, 2000 1 commit
  28. 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
  29. 22 Jan, 2000 1 commit
  30. 09 Jan, 2000 1 commit
  31. 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
  32. 27 Jul, 1999 1 commit
    • 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
  33. 25 Jul, 1999 1 commit
  34. 24 Jul, 1999 1 commit
    • Tom Lane's avatar
      Clean up messy clause-selectivity code in clausesel.c; repair bug · ac4913a0
      Tom Lane authored
      identified by Hiroshi (incorrect cost attributed to OR clauses
      after multiple passes through set_rest_selec()).  I think the code
      was trying to allow selectivities of OR subclauses to be passed in
      from outside, but noplace was actually passing any useful data, and
      set_rest_selec() was passing wrong data.
      
      Restructure representation of "indexqual" in IndexPath nodes so that
      it is the same as for indxqual in completed IndexScan nodes: namely,
      a toplevel list with an entry for each pass of the index scan, having
      sublists that are implicitly-ANDed index qual conditions for that pass.
      You don't want to know what the old representation was :-(
      
      Improve documentation of OR-clause indexscan functions.
      
      Remove useless 'notclause' field from RestrictInfo nodes.  (This might
      force an initdb for anyone who has stored rules containing RestrictInfos,
      but I do not think that RestrictInfo ever appears in completed plans.)
      ac4913a0
  35. 16 Jul, 1999 1 commit
  36. 15 Jul, 1999 2 commits