1. 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
  2. 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
  3. 01 Mar, 2002 1 commit
  4. 25 Oct, 2001 1 commit
  5. 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
  6. 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
  7. 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
  8. 14 May, 2001 1 commit
  9. 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
  10. 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
  11. 22 Mar, 2001 1 commit
  12. 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
  13. 24 Jan, 2001 1 commit
  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. 12 Dec, 2000 1 commit
  16. 23 Nov, 2000 1 commit
  17. 16 Nov, 2000 1 commit
  18. 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
  19. 12 Sep, 2000 1 commit
  20. 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
  21. 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
  22. 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
  23. 12 Apr, 2000 1 commit
  24. 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
  25. 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
  26. 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
  27. 22 Jan, 2000 1 commit
  28. 09 Jan, 2000 1 commit
  29. 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
  30. 26 Aug, 1999 1 commit
  31. 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
  32. 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
  33. 10 Aug, 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
  37. 25 May, 1999 2 commits
  38. 22 Feb, 1999 1 commit