1. 22 Sep, 2007 1 commit
    • Tom Lane's avatar
      Fix cost estimates for EXISTS subqueries that are evaluated as initPlans · 71256875
      Tom Lane authored
      (because they are uncorrelated with the immediate parent query).  We were
      charging the full run cost to the parent node, disregarding the fact that
      only one row need be fetched for EXISTS.  While this would only be a
      cosmetic issue in most cases, it might possibly affect planning outcomes
      if the parent query were itself a subquery to some upper query.
      Per recent discussion with Steve Crawford.
      71256875
  2. 26 Aug, 2007 1 commit
  3. 18 Jul, 2007 1 commit
    • Tom Lane's avatar
      Fix an old thinko in SS_make_initplan_from_plan, which is used when optimizing · d514ea3f
      Tom Lane authored
      a MIN or MAX aggregate call into an indexscan: the initplan is being made at
      the current query nesting level and so we shouldn't increment query_level.
      Though usually harmless, this mistake could lead to bogus "plan should not
      reference subplan's variable" failures on complex queries.  Per bug report
      from David Sanchez i Gregori.
      d514ea3f
  4. 27 Feb, 2007 1 commit
    • Tom Lane's avatar
      Get rid of the separate EState for subplans, and just let them share the · c7ff7663
      Tom Lane authored
      parent query's EState.  Now that there's a single flat rangetable for both
      the main plan and subplans, there's no need anymore for a separate EState,
      and removing it allows cleaning up some crufty code in nodeSubplan.c and
      nodeSubqueryscan.c.  Should be a tad faster too, although any difference
      will probably be hard to measure.  This is the last bit of subsidiary
      mop-up work from changing to a flat rangetable.
      c7ff7663
  5. 22 Feb, 2007 1 commit
    • Tom Lane's avatar
      Turn the rangetable used by the executor into a flat list, and avoid storing · eab6b8b2
      Tom Lane authored
      useless substructure for its RangeTblEntry nodes.  (I chose to keep using the
      same struct node type and just zero out the link fields for unneeded info,
      rather than making a separate ExecRangeTblEntry type --- it seemed too
      fragile to have two different rangetable representations.)
      
      Along the way, put subplans into a list in the toplevel PlannedStmt node,
      and have SubPlan nodes refer to them by list index instead of direct pointers.
      Vadim wanted to do that years ago, but I never understood what he was on about
      until now.  It makes things a *whole* lot more robust, because we can stop
      worrying about duplicate processing of subplans during expression tree
      traversals.  That's been a constant source of bugs, and it's finally gone.
      
      There are some consequent simplifications yet to be made, like not using
      a separate EState for subplans in the executor, but I'll tackle that later.
      eab6b8b2
  6. 19 Feb, 2007 2 commits
    • Tom Lane's avatar
      Get rid of some old and crufty global variables in the planner. When · 7c5e5439
      Tom Lane authored
      this code was last gone over, there wasn't really any alternative to
      globals because we didn't have the PlannerInfo struct being passed all
      through the planner code.  Now that we do, we can restructure things
      to avoid non-reentrancy.  I'm fooling with this because otherwise I'd
      have had to add another global variable for the planned compact
      range table list.
      7c5e5439
    • Tom Lane's avatar
      Put function expressions and values lists into FunctionScan and ValuesScan · b8c32677
      Tom Lane authored
      plan nodes, so that the executor does not need to get these items from
      the range table at runtime.  This will avoid needing to include these
      fields in the compact range table I'm expecting to make the executor use.
      b8c32677
  7. 06 Feb, 2007 1 commit
  8. 10 Jan, 2007 1 commit
    • Tom Lane's avatar
      Change the planner-to-executor API so that the planner tells the executor · a191a169
      Tom Lane authored
      which comparison operators to use for plan nodes involving tuple comparison
      (Agg, Group, Unique, SetOp).  Formerly the executor looked up the default
      equality operator for the datatype, which was really pretty shaky, since it's
      possible that the data being fed to the node is sorted according to some
      nondefault operator class that could have an incompatible idea of equality.
      The planner knows what it has sorted by and therefore can provide the right
      equality operator to use.  Also, this change moves a couple of catalog lookups
      out of the executor and into the planner, which should help startup time for
      pre-planned queries by some small amount.  Modify the planner to remove some
      other cavalier assumptions about always being able to use the default
      operators.  Also add "nulls first/last" info to the Plan node for a mergejoin
      --- neither the executor nor the planner can cope yet, but at least the API is
      in place.
      a191a169
  9. 05 Jan, 2007 1 commit
  10. 23 Dec, 2006 1 commit
    • Tom Lane's avatar
      Restructure operator classes to allow improved handling of cross-data-type · a78fcfb5
      Tom Lane authored
      cases.  Operator classes now exist within "operator families".  While most
      families are equivalent to a single class, related classes can be grouped
      into one family to represent the fact that they are semantically compatible.
      Cross-type operators are now naturally adjunct parts of a family, without
      having to wedge them into a particular opclass as we had done originally.
      
      This commit restructures the catalogs and cleans up enough of the fallout so
      that everything still works at least as well as before, but most of the work
      needed to actually improve the planner's behavior will come later.  Also,
      there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
      to create a new family right now is to allow CREATE OPERATOR CLASS to make
      one by default.  I owe some more documentation work, too.  But that can all
      be done in smaller pieces once this infrastructure is in place.
      a78fcfb5
  11. 10 Dec, 2006 1 commit
    • Tom Lane's avatar
      Add a paramtypmod field to Param nodes. This is dead weight for Params · 9fa12ddd
      Tom Lane authored
      representing externally-supplied values, since the APIs that carry such
      values only specify type not typmod.  However, for PARAM_SUBLINK Params
      it is handy to carry the typmod of the sublink's output column.  This
      is a much cleaner solution for the recently reported 'could not find
      pathkey item to sort' and 'failed to find unique expression in subplan
      tlist' bugs than my original 8.2-compatible patch.  Besides, someday we
      might want to support typmods for external parameters ...
      9fa12ddd
  12. 06 Dec, 2006 1 commit
    • Tom Lane's avatar
      Fix planning of SubLinks to ensure that Vars generated from transformation of · b307d7a6
      Tom Lane authored
      a sublink's test expression have the correct vartypmod, rather than defaulting
      to -1.  There's at least one place where this is important because we're
      expecting these Vars to be exactly equal() to those appearing in the subplan
      itself.  This is a pretty klugy solution --- it would likely be cleaner to
      change Param nodes to include a typmod field --- but we can't do that in the
      already-released 8.2 branch.
      Per bug report from Hubert Fongarnand.
      b307d7a6
  13. 04 Oct, 2006 1 commit
  14. 02 Aug, 2006 1 commit
  15. 14 Jul, 2006 1 commit
  16. 11 Jul, 2006 1 commit
  17. 28 Jun, 2006 1 commit
  18. 03 May, 2006 1 commit
    • Tom Lane's avatar
      Fix calculation of plan node extParams to account for the possibility that one · f4923880
      Tom Lane authored
      initPlan sets a parameter for another.  This could not (I think) happen before
      8.1, but it's possible now because the initPlans generated by MIN/MAX
      optimization might themselves use initPlans.  We attach those initPlans as
      siblings of the MIN/MAX ones, not children, to avoid duplicate computation
      when multiple MIN/MAX aggregates are present; so this leads to the case of an
      initPlan needing the result of a sibling initPlan, which is not possible with
      ordinary query nesting.  Hadn't been noticed because in most contexts having
      too much stuff listed in extParam is fairly harmless.  Fixes "plan should not
      reference subplan's variable" bug reported by Catalin Pitis.
      f4923880
  19. 28 Apr, 2006 1 commit
    • Tom Lane's avatar
      Remove the restriction originally coded into optimize_minmax_aggregates() that · 53ee9f52
      Tom Lane authored
      MIN/MAX not be converted to use an index if the query WHERE clause contains
      any volatile functions or subplans.
      
      I had originally feared that the conversion might alter the behavior of such a
      query with respect to a volatile function.  Well, so it might, but only in the
      sense that the function would get evaluated at a subset of the table rows
      rather than all of them --- and we have never made any such guarantee anyway.
      (For instance, we don't refuse to use an index for an ordinary non-aggregate
      query when one of the non-indexable filter conditions contains a volatile
      function.)
      
      The prohibition against subplans was because of worry that that case wasn't
      adequately tested, which it wasn't, but it turns out to be possible to make
      8.1 fail anyway:
      
      regression=# select o.ten, (select max(unique2) from tenk1 i where ten = o.ten
      or ten = (select f1 from int4_tbl limit 1)) from tenk1 o;
      ERROR:  direct correlated subquery unsupported as initplan
      
      This is due to bogus code in SS_make_initplan_from_plan (it's an initplan,
      ergo it can't have any parParams).  Having fixed that, we might as well allow
      subplans as well as initplans.
      53ee9f52
  20. 22 Apr, 2006 1 commit
  21. 05 Mar, 2006 1 commit
  22. 28 Dec, 2005 1 commit
    • Tom Lane's avatar
      Implement SQL-compliant treatment of row comparisons for < <= > >= cases · 6e077097
      Tom Lane authored
      (previously we only did = and <> correctly).  Also, allow row comparisons
      with any operators that are in btree opclasses, not only those with these
      specific names.  This gets rid of a whole lot of indefensible assumptions
      about the behavior of particular operators based on their names ... though
      it's still true that IN and NOT IN expand to "= ANY".  The patch adds a
      RowCompareExpr expression node type, and makes some changes in the
      representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code
      with RowCompareExpr.
      
      I have not yet done anything about making RowCompareExpr an indexable
      operator, but will look at that soon.
      
      initdb forced due to changes in stored rules.
      6e077097
  23. 26 Nov, 2005 1 commit
  24. 22 Nov, 2005 1 commit
  25. 15 Oct, 2005 1 commit
  26. 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
  27. 25 Apr, 2005 1 commit
    • Tom Lane's avatar
      Remove support for OR'd indexscans internal to a single IndexScan plan · 5b051852
      Tom Lane authored
      node, as this behavior is now better done as a bitmap OR indexscan.
      This allows considerable simplification in nodeIndexscan.c itself as
      well as several planner modules concerned with indexscan plan generation.
      Also we can improve the sharing of code between regular and bitmap
      indexscans, since they are now working with nigh-identical Plan nodes.
      5b051852
  28. 19 Apr, 2005 1 commit
    • Tom Lane's avatar
      Create executor and planner-backend support for decoupled heap and index · 4a8c5d03
      Tom Lane authored
      scans, using in-memory tuple ID bitmaps as the intermediary.  The planner
      frontend (path creation and cost estimation) is not there yet, so none
      of this code can be executed.  I have tested it using some hacked planner
      code that is far too ugly to see the light of day, however.  Committing
      now so that the bulk of the infrastructure changes go in before the tree
      drifts under me.
      4a8c5d03
  29. 11 Apr, 2005 1 commit
  30. 06 Apr, 2005 1 commit
    • Tom Lane's avatar
      Merge Resdom nodes into TargetEntry nodes to simplify code and save a · ad161bcc
      Tom Lane authored
      few palloc's.  I also chose to eliminate the restype and restypmod fields
      entirely, since they are redundant with information stored in the node's
      contained expression; re-examining the expression at need seems simpler
      and more reliable than trying to keep restype/restypmod up to date.
      
      initdb forced due to change in contents of stored rules.
      ad161bcc
  31. 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
  32. 29 Aug, 2004 2 commits
  33. 30 May, 2004 1 commit
  34. 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
  35. 11 May, 2004 1 commit
  36. 03 Feb, 2004 1 commit
    • Tom Lane's avatar
      Rename SortMem and VacuumMem to work_mem and maintenance_work_mem. · 391c3811
      Tom Lane authored
      Make btree index creation and initial validation of foreign-key constraints
      use maintenance_work_mem rather than work_mem as their memory limit.
      Add some code to guc.c to allow these variables to be referenced by their
      old names in SHOW and SET commands, for backwards compatibility.
      391c3811
  37. 12 Jan, 2004 1 commit
  38. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad