1. 08 Nov, 2007 2 commits
    • Tom Lane's avatar
      Fix EquivalenceClass code to handle volatile sort expressions in a more · c291203c
      Tom Lane authored
      predictable manner; in particular that if you say ORDER BY output-column-ref,
      it will in fact sort by that specific column even if there are multiple
      syntactic matches.  An example is
      	SELECT random() AS a, random() AS b FROM ... ORDER BY b, a;
      While the use-case for this might be a bit debatable, it worked as expected
      in earlier releases, so we should preserve the behavior for 8.3.  Per my
      recent proposal.
      
      While at it, fix convert_subquery_pathkeys() to handle RelabelType stripping
      in both directions; it needs this for the same reasons make_sort_from_pathkeys
      does.
      c291203c
    • Tom Lane's avatar
      Last week's patch for make_sort_from_pathkeys wasn't good enough: it has · 1be06016
      Tom Lane authored
      to be able to discard top-level RelabelType nodes on *both* sides of the
      equivalence-class-to-target-list comparison, since make_pathkey_from_sortinfo
      might either add or remove a RelabelType.  Also fix the latter to do the
      removal case cleanly.  Per example from Peter.
      1be06016
  2. 02 Nov, 2007 1 commit
    • Tom Lane's avatar
      Ensure that EquivalenceClasses generated from ORDER BY keys contain proper · 97ddfc96
      Tom Lane authored
      RelabelType nodes when the sort key is binary-compatible with the sort
      operator rather than having exactly its input type.  We did this correctly
      for index columns but not sort keys, leading to failure to notice that
      a varchar index matches an ORDER BY request.  This requires a bit more work
      in make_sort_from_pathkeys, but not anyplace else that I can find.
      Per bug report and subsequent discussion.
      97ddfc96
  3. 27 Oct, 2007 1 commit
    • Tom Lane's avatar
      Avoid considering both sort directions as equally useful for merging. · 834ddc62
      Tom Lane authored
      This doubles the planning workload for mergejoins while not actually
      accomplishing much.  The only useful case is where one of the directions
      matches the query's ORDER BY request; therefore, put a thumb on the scales
      in that direction, and otherwise arbitrarily consider only the ASC direction.
      (This is a lot easier now than it would've been before 8.3, since we have
      more semantic knowledge embedded in PathKeys now.)
      834ddc62
  4. 31 May, 2007 1 commit
    • Tom Lane's avatar
      Change build_index_pathkeys() so that the expressions it builds to represent · 10f719af
      Tom Lane authored
      index key columns always have the type expected by the index's associated
      operators, ie, we add RelabelType nodes when dealing with binary-compatible
      index opclasses.  This is needed to get varchar indexes to play nicely with
      the new EquivalenceClass machinery, as per recent gripe from Josh Berkus that
      CVS HEAD was failing to match a varchar index column to a constant restriction
      in the query.
      
      It seems likely that this change will allow removal of a lot of ugly ad-hoc
      RelabelType-stripping that the planner has traditionally done while matching
      expressions to other expressions, but I'll worry about that some other day.
      10f719af
  5. 15 Apr, 2007 1 commit
  6. 21 Jan, 2007 1 commit
  7. 20 Jan, 2007 1 commit
    • Tom Lane's avatar
      Refactor planner's pathkeys data structure to create a separate, explicit · f41803bb
      Tom Lane authored
      representation of equivalence classes of variables.  This is an extensive
      rewrite, but it brings a number of benefits:
      * planner no longer fails in the presence of "incomplete" operator families
      that don't offer operators for every possible combination of datatypes.
      * avoid generating and then discarding redundant equality clauses.
      * remove bogus assumption that derived equalities always use operators
      named "=".
      * mergejoins can work with a variety of sort orders (e.g., descending) now,
      instead of tying each mergejoinable operator to exactly one sort order.
      * better recognition of redundant sort columns.
      * can make use of equalities appearing underneath an outer join.
      f41803bb
  8. 09 Jan, 2007 1 commit
    • Tom Lane's avatar
      Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST · 44317582
      Tom Lane authored
      per-column options for btree indexes.  The planner's support for this is still
      pretty rudimentary; it does not yet know how to plan mergejoins with
      nondefault ordering options.  The documentation is pretty rudimentary, too.
      I'll work on improving that stuff later.
      
      Note incompatible change from prior behavior: ORDER BY ... USING will now be
      rejected if the operator is not a less-than or greater-than member of some
      btree opclass.  This prevents less-than-sane behavior if an operator that
      doesn't actually define a proper sort ordering is selected.
      44317582
  9. 05 Jan, 2007 1 commit
  10. 04 Oct, 2006 1 commit
  11. 17 Aug, 2006 1 commit
    • Tom Lane's avatar
      Teach convert_subquery_pathkeys() to handle the case where the · 144b0ae8
      Tom Lane authored
      subquery's pathkey is a RelabelType applied to something that appears
      in the subquery's output; for example where the subquery returns a
      varchar Var and the sort order is shown as that Var coerced to text.
      This comes up because varchar doesn't have its own sort operator.
      Per example from Peter Hardman.
      144b0ae8
  12. 14 Jul, 2006 1 commit
  13. 05 Mar, 2006 1 commit
  14. 29 Jan, 2006 1 commit
    • Tom Lane's avatar
      Fix code that checks to see if an index can be considered to match the query's · a1b7e70c
      Tom Lane authored
      requested sort order.  It was assuming that build_index_pathkeys always
      generates a pathkey per index column, which was not true if implied equality
      deduction had determined that two index columns were effectively equated to
      each other.  Simplest fix seems to be to install an option that causes
      build_index_pathkeys to support this behavior as well as the original one.
      Per report from Brian Hirt.
      a1b7e70c
  15. 22 Nov, 2005 1 commit
  16. 15 Oct, 2005 1 commit
  17. 27 Aug, 2005 1 commit
    • Tom Lane's avatar
      Change the division of labor between grouping_planner and query_planner · 4e5fbb34
      Tom Lane authored
      so that the latter estimates the number of groups that grouping will
      produce.  This is needed because it is primarily query_planner that
      makes the decision between fast-start and fast-finish plans, and in the
      original coding it was unable to make more than a crude rule-of-thumb
      choice when the query involved grouping.  This revision helps us make
      saner choices for queries like SELECT ... GROUP BY ... LIMIT, as in a
      recent example from Mark Kirkwood.  Also move the responsibility for
      canonicalizing sort_pathkeys and group_pathkeys into query_planner;
      this information has to be available anyway to support the first change,
      and doing it this way lets us get rid of compare_noncanonical_pathkeys
      entirely.
      4e5fbb34
  18. 28 Jul, 2005 1 commit
  19. 03 Jul, 2005 1 commit
  20. 02 Jul, 2005 1 commit
    • Tom Lane's avatar
      Teach planner about some cases where a restriction clause can be · cc5e80b8
      Tom Lane authored
      propagated inside an outer join.  In particular, given
      LEFT JOIN ON (A = B) WHERE A = constant, we cannot conclude that
      B = constant at the top level (B might be null instead), but we
      can nonetheless put a restriction B = constant into the quals for
      B's relation, since no inner-side rows not meeting that condition
      can contribute to the final result.  Similarly, given
      FULL JOIN USING (J) WHERE J = constant, we can't directly conclude
      that either input J variable = constant, but it's OK to push such
      quals into each input rel.  Per recent gripe from Kim Bisgaard.
      Along the way, remove 'valid_everywhere' flag from RestrictInfo,
      as on closer analysis it was not being used for anything, and was
      defined backwards anyway.
      cc5e80b8
  21. 09 Jun, 2005 1 commit
    • Tom Lane's avatar
      Simplify the planner's join clause management by storing join clauses · a31ad27f
      Tom Lane authored
      of a relation in a flat 'joininfo' list.  The former arrangement grouped
      the join clauses according to the set of unjoined relids used in each;
      however, profiling on test cases involving lots of joins proves that
      that data structure is a net loss.  It takes more time to group the
      join clauses together than is saved by avoiding duplicate tests later.
      It doesn't help any that there are usually not more than one or two
      clauses per group ...
      a31ad27f
  22. 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
  23. 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
  24. 27 Mar, 2005 1 commit
  25. 23 Jan, 2005 1 commit
  26. 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
  27. 29 Aug, 2004 2 commits
  28. 05 Jun, 2004 1 commit
    • Tom Lane's avatar
      Make the world very nearly safe for composite-type columns in tables. · ae93e5fd
      Tom Lane authored
      1. Solve the problem of not having TOAST references hiding inside composite
      values by establishing the rule that toasting only goes one level deep:
      a tuple can contain toasted fields, but a composite-type datum that is
      to be inserted into a tuple cannot.  Enforcing this in heap_formtuple
      is relatively cheap and it avoids a large increase in the cost of running
      the tuptoaster during final storage of a row.
      2. Fix some interesting problems in expansion of inherited queries that
      reference whole-row variables.  We never really did this correctly before,
      but it's now relatively painless to solve by expanding the parent's
      whole-row Var into a RowExpr() selecting the proper columns from the
      child.
      If you dike out the preventive check in CheckAttributeType(),
      composite-type columns now seem to actually work.  However, we surely
      cannot ship them like this --- without I/O for composite types, you
      can't get pg_dump to dump tables containing them.  So a little more
      work still to do.
      ae93e5fd
  29. 01 Jun, 2004 1 commit
  30. 30 May, 2004 1 commit
  31. 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
  32. 07 Apr, 2004 1 commit
  33. 03 Dec, 2003 1 commit
  34. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  35. 04 Aug, 2003 2 commits
  36. 25 Jul, 2003 1 commit
  37. 29 Jun, 2003 1 commit
    • Tom Lane's avatar
      Restructure building of join relation targetlists so that a join plan · 835bb975
      Tom Lane authored
      node emits only those vars that are actually needed above it in the
      plan tree.  (There were comments in the code suggesting that this was
      done at some point in the dim past, but for a long time we have just
      made join nodes emit everything that either input emitted.)  Aside from
      being marginally more efficient, this fixes the problem noted by Peter
      Eisentraut where a join above an IN-implemented-as-join might fail,
      because the subplan targetlist constructed in the latter case didn't
      meet the expectation of including everything.
      Along the way, fix some places that were O(N^2) in the targetlist
      length.  This is not all the trouble spots for wide queries by any
      means, but it's a step forward.
      835bb975