1. 22 Oct, 2008 1 commit
    • Tom Lane's avatar
      Dept of better ideas: refrain from creating the planner's placeholder_list · 31468d05
      Tom Lane authored
      until vars are distributed to rels during query_planner() startup.  We don't
      really need it before that, and not building it early has some advantages.
      First, we don't need to put it through the various preprocessing steps, which
      saves some cycles and eliminates the need for a number of routines to support
      PlaceHolderInfo nodes at all.  Second, this means one less unused plan for any
      sub-SELECT appearing in a placeholder's expression, since we don't build
      placeholder_list until after sublink expansion is complete.
      31468d05
  2. 21 Oct, 2008 1 commit
    • Tom Lane's avatar
      Add a concept of "placeholder" variables to the planner. These are variables · e6ae3b5d
      Tom Lane authored
      that represent some expression that we desire to compute below the top level
      of the plan, and then let that value "bubble up" as though it were a plain
      Var (ie, a column value).
      
      The immediate application is to allow sub-selects to be flattened even when
      they are below an outer join and have non-nullable output expressions.
      Formerly we couldn't flatten because such an expression wouldn't properly
      go to NULL when evaluated above the outer join.  Now, we wrap it in a
      PlaceHolderVar and arrange for the actual evaluation to occur below the outer
      join.  When the resulting Var bubbles up through the join, it will be set to
      NULL if necessary, yielding the correct results.  This fixes a planner
      limitation that's existed since 7.1.
      
      In future we might want to use this mechanism to re-introduce some form of
      Hellerstein's "expensive functions" optimization, ie place the evaluation of
      an expensive function at the most suitable point in the plan tree.
      e6ae3b5d
  3. 06 Oct, 2008 1 commit
    • Tom Lane's avatar
      When expanding a whole-row Var into a RowExpr during ResolveNew(), attach · bf461538
      Tom Lane authored
      the column alias names of the RTE referenced by the Var to the RowExpr.
      This is needed to allow ruleutils.c to correctly deparse FieldSelect nodes
      referencing such a construct.  Per my recent bug report.
      
      Adding a field to RowExpr forces initdb (because of stored rules changes)
      so this solution is not back-patchable; which is unfortunate because 8.2
      and 8.3 have this issue.  But it only affects EXPLAIN for some pretty odd
      corner cases, so we can probably live without a solution for the back
      branches.
      bf461538
  4. 01 Sep, 2008 1 commit
  5. 28 Aug, 2008 1 commit
    • Tom Lane's avatar
      Extend the parser location infrastructure to include a location field in · a2794623
      Tom Lane authored
      most node types used in expression trees (both before and after parse
      analysis).  This allows us to place an error cursor in many situations
      where we formerly could not, because the information wasn't available
      beyond the very first level of parse analysis.  There's a fair amount
      of work still to be done to persuade individual ereport() calls to actually
      include an error location, but this gets the initdb-forcing part of the
      work out of the way; and the situation is already markedly better than
      before for complaints about unimplementable implicit casts, such as
      CASE and UNION constructs with incompatible alternative data types.
      Per my proposal of a few days ago.
      a2794623
  6. 25 Aug, 2008 1 commit
  7. 22 Aug, 2008 1 commit
    • Tom Lane's avatar
      Arrange to convert EXISTS subqueries that are equivalent to hashable IN · bd3dadda
      Tom Lane authored
      subqueries into the same thing you'd have gotten from IN (except always with
      unknownEqFalse = true, so as to get the proper semantics for an EXISTS).
      I believe this fixes the last case within CVS HEAD in which an EXISTS could
      give worse performance than an equivalent IN subquery.
      
      The tricky part of this is that if the upper query probes the EXISTS for only
      a few rows, the hashing implementation can actually be worse than the default,
      and therefore we need to make a cost-based decision about which way to use.
      But at the time when the planner generates plans for subqueries, it doesn't
      really know how many times the subquery will be executed.  The least invasive
      solution seems to be to generate both plans and postpone the choice until
      execution.  Therefore, in a query that has been optimized this way, EXPLAIN
      will show two subplans for the EXISTS, of which only one will actually get
      executed.
      
      There is a lot more that could be done based on this infrastructure: in
      particular it's interesting to consider switching to the hash plan if we start
      out using the non-hashed plan but find a lot more upper rows going by than we
      expected.  I have therefore left some minor inefficiencies in place, such as
      initializing both subplans even though we will currently only use one.
      bd3dadda
  8. 14 Aug, 2008 1 commit
    • Tom Lane's avatar
      Implement SEMI and ANTI joins in the planner and executor. (Semijoins replace · e006a24a
      Tom Lane authored
      the old JOIN_IN code, but antijoins are new functionality.)  Teach the planner
      to convert appropriate EXISTS and NOT EXISTS subqueries into semi and anti
      joins respectively.  Also, LEFT JOINs with suitable upper-level IS NULL
      filters are recognized as being anti joins.  Unify the InClauseInfo and
      OuterJoinInfo infrastructure into "SpecialJoinInfo".  With that change,
      it becomes possible to associate a SpecialJoinInfo with every join attempt,
      which permits some cleanup of join selectivity estimation.  That needs to be
      taken much further than this patch does, but the next step is to change the
      API for oprjoin selectivity functions, which seems like material for a
      separate patch.  So for the moment the output size estimates for semi and
      especially anti joins are quite bogus.
      e006a24a
  9. 12 May, 2008 1 commit
    • Alvaro Herrera's avatar
      Restructure some header files a bit, in particular heapam.h, by removing some · f8c4d7db
      Alvaro Herrera authored
      unnecessary #include lines in it.  Also, move some tuple routine prototypes and
      macros to htup.h, which allows removal of heapam.h inclusion from some .c
      files.
      
      For this to work, a new header file access/sysattr.h needed to be created,
      initially containing attribute numbers of system columns, for pg_dump usage.
      
      While at it, make contrib ltree, intarray and hstore header files more
      consistent with our header style.
      f8c4d7db
  10. 01 Jan, 2008 1 commit
  11. 15 Nov, 2007 1 commit
  12. 20 Sep, 2007 1 commit
    • Tom Lane's avatar
      HOT updates. When we update a tuple without changing any of its indexed · 282d2a03
      Tom Lane authored
      columns, and the new version can be stored on the same heap page, we no longer
      generate extra index entries for the new version.  Instead, index searches
      follow the HOT-chain links to ensure they find the correct tuple version.
      
      In addition, this patch introduces the ability to "prune" dead tuples on a
      per-page basis, without having to do a complete VACUUM pass to recover space.
      VACUUM is still needed to clean up dead index entries, however.
      
      Pavan Deolasee, with help from a bunch of other people.
      282d2a03
  13. 11 Jun, 2007 1 commit
    • Tom Lane's avatar
      Support UPDATE/DELETE WHERE CURRENT OF cursor_name, per SQL standard. · 6808f1b1
      Tom Lane authored
      Along the way, allow FOR UPDATE in non-WITH-HOLD cursors; there may once
      have been a reason to disallow that, but it seems to work now, and it's
      really rather necessary if you want to select a row via a cursor and then
      update it in a concurrent-safe fashion.
      
      Original patch by Arul Shaji, rather heavily editorialized by Tom Lane.
      6808f1b1
  14. 05 Jan, 2007 1 commit
  15. 14 Jul, 2006 1 commit
  16. 05 Mar, 2006 1 commit
  17. 15 Oct, 2005 1 commit
  18. 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
  19. 03 Jun, 2005 1 commit
    • Tom Lane's avatar
      Revise handling of dropped columns in JOIN alias lists to avoid a · ba420024
      Tom Lane authored
      performance problem pointed out by phil@vodafone: to wit, we were
      spending O(N^2) time to check dropped-ness in an N-deep join tree,
      even in the case where the tree was freshly constructed and couldn't
      possibly mention any dropped columns.  Instead of recursing in
      get_rte_attribute_is_dropped(), change the data structure definition:
      the joinaliasvars list of a JOIN RTE must have a NULL Const instead
      of a Var at any position that references a now-dropped column.  This
      costs nothing during normal parse-rewrite-plan path, and instead we
      have a linear-time update to make when loading a stored rule that
      might contain now-dropped columns.  While at it, move the responsibility
      for acquring locks on relations referenced by rules into this separate
      function (which I therefore chose to call AcquireRewriteLocks).
      This saves effort --- namely, duplicated lock grabs in parser and rewriter
      --- in the normal path at a cost of one extra non-locked heap_open()
      in the stored-rule path; seems a good tradeoff.  A fringe benefit is
      that it is now *much* clearer that we acquire lock on relations referenced
      in rules before we make any rewriter decisions based on their properties.
      (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
      ba420024
  20. 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
  21. 29 Aug, 2004 2 commits
  22. 19 Aug, 2004 1 commit
    • Tom Lane's avatar
      Repair some issues with column aliases and RowExpr construction in the · bbd6eb5b
      Tom Lane authored
      presence of dropped columns.  Document the already-presumed fact that
      eref aliases in relation RTEs are supposed to have entries for dropped
      columns; cause the user alias structs to have such entries too, so that
      there's always a one-to-one mapping to the underlying physical attnums.
      Adjust expandRTE() and related code to handle the case where a column
      that is part of a JOIN has been dropped.  Generalize expandRTE()'s API
      so that it can be used in a couple of places that formerly rolled their
      own implementation of the same logic.  Fix ruleutils.c to suppress
      display of aliases for columns that were dropped since the rule was made.
      bbd6eb5b
  23. 01 Jun, 2004 1 commit
  24. 30 May, 2004 1 commit
  25. 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
  26. 10 May, 2004 1 commit
    • Tom Lane's avatar
      Promote row expressions to full-fledged citizens of the expression syntax, · 2f63232d
      Tom Lane authored
      rather than allowing them only in a few special cases as before.  In
      particular you can now pass a ROW() construct to a function that accepts
      a rowtype parameter.  Internal generation of RowExprs fixes a number of
      corner cases that used to not work very well, such as referencing the
      whole-row result of a JOIN or subquery.  This represents a further step in
      the work I started a month or so back to make rowtype values into
      first-class citizens.
      2f63232d
  27. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  28. 08 Aug, 2003 1 commit
  29. 04 Aug, 2003 2 commits
  30. 06 Jun, 2003 1 commit
    • Tom Lane's avatar
      Implement outer-level aggregates to conform to the SQL spec, with · e649796f
      Tom Lane authored
      extensions to support our historical behavior.  An aggregate belongs
      to the closest query level of any of the variables in its argument,
      or the current query level if there are no variables (e.g., COUNT(*)).
      The implementation involves adding an agglevelsup field to Aggref,
      and treating outer aggregates like outer variables at planning time.
      e649796f
  31. 28 May, 2003 1 commit
  32. 08 Feb, 2003 1 commit
  33. 06 Feb, 2003 1 commit
  34. 20 Jan, 2003 1 commit
    • Tom Lane's avatar
      IN clauses appearing at top level of WHERE can now be handled as joins. · bdfbfde1
      Tom Lane authored
      There are two implementation techniques: the executor understands a new
      JOIN_IN jointype, which emits at most one matching row per left-hand row,
      or the result of the IN's sub-select can be fed through a DISTINCT filter
      and then joined as an ordinary relation.
      Along the way, some minor code cleanup in the optimizer; notably, break
      out most of the jointree-rearrangement preprocessing in planner.c and
      put it in a new file prep/prepjointree.c.
      bdfbfde1
  35. 17 Jan, 2003 1 commit
  36. 16 Jan, 2003 1 commit
  37. 15 Jan, 2003 1 commit
    • Tom Lane's avatar
      Allow merge and hash joins to occur on arbitrary expressions (anything not · de97072e
      Tom Lane authored
      containing a volatile function), rather than only on 'Var = Var' clauses
      as before.  This makes it practical to do flatten_join_alias_vars at the
      start of planning, which in turn eliminates a bunch of klugery inside the
      planner to deal with alias vars.  As a free side effect, we now detect
      implied equality of non-Var expressions; for example in
      	SELECT ... WHERE a.x = b.y and b.y = 42
      we will deduce a.x = 42 and use that as a restriction qual on a.  Also,
      we can remove the restriction introduced 12/5/02 to prevent pullup of
      subqueries whose targetlists contain sublinks.
      Still TODO: make statistical estimation routines in selfuncs.c and costsize.c
      smarter about expressions that are more complex than plain Vars.  The need
      for this is considerably greater now that we have to be able to estimate
      the suitability of merge and hash join techniques on such expressions.
      de97072e
  38. 10 Jan, 2003 1 commit