1. 17 Oct, 2008 1 commit
  2. 04 Oct, 2008 1 commit
    • Tom Lane's avatar
      Implement SQL-standard WITH clauses, including WITH RECURSIVE. · 44d5be0e
      Tom Lane authored
      There are some unimplemented aspects: recursive queries must use UNION ALL
      (should allow UNION too), and we don't have SEARCH or CYCLE clauses.
      These might or might not get done for 8.4, but even without them it's a
      pretty useful feature.
      
      There are also a couple of small loose ends and definitional quibbles,
      which I'll send a memo about to pgsql-hackers shortly.  But let's land
      the patch now so we can get on with other development.
      
      Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane
      44d5be0e
  3. 09 Sep, 2008 1 commit
    • Tom Lane's avatar
      Improve the plan cache invalidation mechanism to make it invalidate plans · ee33b95d
      Tom Lane authored
      when user-defined functions used in a plan are modified.  Also invalidate
      plans when schemas, operators, or operator classes are modified; but for these
      cases we just invalidate everything rather than tracking exact dependencies,
      since these types of objects seldom change in a production database.
      
      Tom Lane; loosely based on a patch by Martin Pihlak.
      ee33b95d
  4. 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
  5. 05 Aug, 2008 1 commit
    • Tom Lane's avatar
      Improve SELECT DISTINCT to consider hash aggregation, as well as sort/uniq, · be3b265c
      Tom Lane authored
      as methods for implementing the DISTINCT step.  This eliminates the former
      performance gap between DISTINCT and GROUP BY, and also makes it possible
      to do SELECT DISTINCT on datatypes that only support hashing not sorting.
      
      SELECT DISTINCT ON is still always implemented by sorting; it would take
      executor changes to support hashing that, and it's not clear it's worth
      the trouble.
      
      This is a release-note-worthy incompatibility from previous PG versions,
      since SELECT DISTINCT can no longer be counted on to deliver sorted output
      without explicitly saying ORDER BY.  (Anyone who can't cope with that
      can consider turning off enable_hashagg.)
      
      Several regression test queries needed to have ORDER BY added to preserve
      stable output order.  I fixed the ones that manifested here, but there
      might be some other cases that show up on other platforms.
      be3b265c
  6. 21 Apr, 2008 1 commit
    • Tom Lane's avatar
      Fix convert_IN_to_join to properly handle the case where the subselect's · ff673f55
      Tom Lane authored
      output is not of the same type that's needed for the IN comparison (ie,
      where the parser inserted an implicit coercion above the subselect result).
      We should record the coerced expression, not just a raw Var referencing
      the subselect output, as the quantity that needs to be unique-ified if
      we choose to implement the IN as Unique followed by a plain join.
      
      As of 8.3 this error was causing crashes, as seen in bug #4113 from Javier
      Hernandez, because the executor was being told to hash or sort the raw
      subselect output column using operators appropriate to the coerced type.
      
      In prior versions there was no crash because the executor chose the
      hash or sort operators for itself based on the column type it saw.
      However, that's still not really right, because what's unique for one data
      type might not be unique for another.  In corner cases we could get multiple
      outputs of a row that should appear only once, as demonstrated by the
      regression test case included in this commit.
      
      However, this patch doesn't apply cleanly to 8.2 or before, and the code
      involved has shifted enough over time that I'm hesitant to try to back-patch.
      Given the lack of complaints from the field about such corner cases, I think
      the bug may not be important enough to risk breaking other things with a
      back-patch.
      ff673f55
  7. 24 Mar, 2008 1 commit
    • Tom Lane's avatar
      When a relation has been proven empty by constraint exclusion, propagate that · fd791e7b
      Tom Lane authored
      knowledge up through any joins it participates in.  We were doing that already
      in some special cases but not in the general case.  Also, defend against zero
      row estimates for the input relations in cost_mergejoin --- this fix may have
      eliminated the only scenario in which that can happen, but be safe.  Per
      report from Alex Solovey.
      fd791e7b
  8. 11 Jan, 2008 1 commit
    • Tom Lane's avatar
      Fix a conceptual error in my patch of 2007-10-26 that avoided considering · 59fc64ac
      Tom Lane authored
      clauseless joins of relations that have unexploited join clauses.  Rather
      than looking at every other base relation in the query, the correct thing is
      to examine the other relations in the "initial_rels" list of the current
      make_rel_from_joinlist() invocation, because those are what we actually have
      the ability to join against.  This might be a subset of the whole query in
      cases where join_collapse_limit or from_collapse_limit or full joins have
      prevented merging the whole query into a single join problem.  This is a bit
      untidy because we have to pass those rels down through a new PlannerInfo
      field, but it's necessary.  Per bug #3865 from Oleg Kharin.
      59fc64ac
  9. 09 Jan, 2008 1 commit
    • Tom Lane's avatar
      Fix some planner issues found while investigating Kevin Grittner's report · 6a652252
      Tom Lane authored
      of poorer planning in 8.3 than 8.2:
      
      1. After pushing a constant across an outer join --- ie, given
      "a LEFT JOIN b ON (a.x = b.y) WHERE a.x = 42", we can deduce that b.y is
      sort of equal to 42, in the sense that we needn't fetch any b rows where
      it isn't 42 --- loop to see if any additional deductions can be made.
      Previous releases did that by recursing, but I had mistakenly thought that
      this was no longer necessary given the EquivalenceClass machinery.
      
      2. Allow pushing constants across outer join conditions even if the
      condition is outerjoin_delayed due to a lower outer join.  This is safe
      as long as the condition is strict and we re-test it at the upper join.
      
      3. Keep the outer-join clause even if we successfully push a constant
      across it.  This is *necessary* in the outerjoin_delayed case, but
      even in the simple case, it seems better to do this to ensure that the
      join search order heuristics will consider the join as reasonable to
      make.  Mark such a clause as having selectivity 1.0, though, since it's
      not going to eliminate very many rows after application of the constant
      condition.
      
      4. Tweak have_relevant_eclass_joinclause to report that two relations
      are joinable when they have vars that are equated to the same constant.
      We won't actually generate any joinclause from such an EquivalenceClass,
      but again it seems that in such a case it's a good idea to consider
      the join as worth costing out.
      
      5. Fix a bug in select_mergejoin_clauses that was exposed by these
      changes: we have to reject candidate mergejoin clauses if either side was
      equated to a constant, because we can't construct a canonical pathkey list
      for such a clause.  This is an implementation restriction that might be
      worth fixing someday, but it doesn't seem critical to get it done for 8.3.
      6a652252
  10. 01 Jan, 2008 1 commit
  11. 08 Dec, 2007 1 commit
    • Tom Lane's avatar
      Fix mergejoin cost estimation so that we consider the statistical ranges of · 9fd88436
      Tom Lane authored
      the two join variables at both ends: not only trailing rows that need not be
      scanned because there cannot be a match on the other side, but initial rows
      that will be scanned without possibly having a match.  This allows a more
      realistic estimate of startup cost to be made, per recent pgsql-performance
      discussion.  In passing, fix a couple of bugs that had crept into
      mergejoinscansel: it was not quite up to speed for the task of estimating
      descending-order scans, which is a new requirement in 8.3.
      9fd88436
  12. 15 Nov, 2007 2 commits
  13. 08 Nov, 2007 1 commit
    • 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
  14. 11 Oct, 2007 1 commit
    • Tom Lane's avatar
      Fix the plan-invalidation mechanism to treat regclass constants that refer to · 82d8ab6f
      Tom Lane authored
      a relation as a reason to invalidate a plan when the relation changes.  This
      handles scenarios such as dropping/recreating a sequence that is referenced by
      nextval('seq') in a cached plan.  Rather than teach plancache.c all about
      digging through plan trees to find regclass Consts, we charge the planner's
      setrefs.c with making a list of the relation OIDs on which each plan depends.
      That way the list can be built cheaply during a plan tree traversal that has
      to happen anyway.  Per bug #3662 and subsequent discussion.
      82d8ab6f
  15. 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
  16. 31 Aug, 2007 1 commit
    • Tom Lane's avatar
      Rewrite make_outerjoininfo's construction of min_lefthand and min_righthand · b4c806fa
      Tom Lane authored
      sets for outer joins, in the light of bug #3588 and additional thought and
      experimentation.  The original methodology was fatally flawed for nests of
      more than two outer joins: it got the relationships between adjacent joins
      right, but didn't always come to the right conclusions about whether a join
      could be interchanged with one two or more levels below it.  This was largely
      caused by a mistaken idea that we should use the min_lefthand + min_righthand
      sets of a sub-join as the minimum left or right input set of an upper join
      when we conclude that the sub-join can't commute with the upper one.  If
      there's a still-lower join that the sub-join *can* commute with, this method
      led us to think that that one could commute with the topmost join; which it
      can't.  Another problem (not directly connected to bug #3588) was that
      make_outerjoininfo's processing-order-dependent method for enforcing outer
      join identity #3 didn't work right: if we decided that join A could safely
      commute with lower join B, we dropped all information about sub-joins under B
      that join A could perhaps not safely commute with, because we removed B's
      entire min_righthand from A's.
      
      To fix, make an explicit computation of all inner join combinations that occur
      below an outer join, and add to that the full syntactic relsets of any lower
      outer joins that we determine it can't commute with.  This method gives much
      more direct enforcement of the outer join rearrangement identities, and it
      turns out not to cost a lot of additional bookkeeping.
      
      Thanks to Richard Harris for the bug report and test case.
      b4c806fa
  17. 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
  18. 22 May, 2007 2 commits
    • Tom Lane's avatar
      Repair planner bug introduced in 8.2 by ability to rearrange outer joins: · 11086f2f
      Tom Lane authored
      in cases where a sub-SELECT inserts a WHERE clause between two outer joins,
      that clause may prevent us from re-ordering the two outer joins.  The code
      was considering only the joins' own ON-conditions in determining reordering
      safety, which is not good enough.  Add a "delay_upper_joins" flag to
      OuterJoinInfo to flag that we have detected such a clause and higher-level
      outer joins shouldn't be permitted to commute with this one.  (This might
      seem overly coarse, but given the current rules for OJ reordering, it's
      sufficient AFAICT.)
      
      The failure case is actually pretty narrow: it needs a WHERE clause within
      the RHS of a left join that checks the RHS of a lower left join, but is not
      strict for that RHS (else we'd have simplified the lower join to a plain
      join).  Even then no failure will be manifest unless the planner chooses to
      rearrange the join order.
      
      Per bug report from Adam Terrey.
      11086f2f
    • Tom Lane's avatar
      Fix best_inner_indexscan to return both the cheapest-total-cost and · d7153c5f
      Tom Lane authored
      cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider
      both of these (when different) as the inside of a nestloop join.  The
      original design was based on the assumption that indexscan paths always
      have negligible startup cost, and so total cost is the only important
      figure of merit; an assumption that's obviously broken by bitmap
      indexscans.  This oversight could lead to choosing poor plans in cases
      where fast-start behavior is more important than total cost, such as
      LIMIT and IN queries.  8.1-vintage brain fade exposed by an example from
      Chuck D.
      d7153c5f
  19. 21 Apr, 2007 1 commit
    • Tom Lane's avatar
      Some further performance tweaks for planning large inheritance trees that · afcf09dd
      Tom Lane authored
      are mostly excluded by constraints: do the CE test a bit earlier to save
      some adjust_appendrel_attrs() work on excluded children, and arrange to
      use array indexing rather than rt_fetch() to fetch RTEs in the main body
      of the planner.  The latter is something I'd wanted to do for awhile anyway,
      but seeing list_nth_cell() as 35% of the runtime gets one's attention.
      afcf09dd
  20. 06 Apr, 2007 1 commit
  21. 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
  22. 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
  23. 20 Feb, 2007 1 commit
    • Tom Lane's avatar
      Remove the Query structure from the executor's API. This allows us to stop · 9cbd0c15
      Tom Lane authored
      storing mostly-redundant Query trees in prepared statements, portals, etc.
      To replace Query, a new node type called PlannedStmt is inserted by the
      planner at the top of a completed plan tree; this carries just the fields of
      Query that are still needed at runtime.  The statement lists kept in portals
      etc. now consist of intermixed PlannedStmt and bare utility-statement nodes
      --- no Query.  This incidentally allows us to remove some fields from Query
      and Plan nodes that shouldn't have been there in the first place.
      
      Still to do: simplify the execution-time range table; at the moment the
      range table passed to the executor still contains Query trees for subqueries.
      
      initdb forced due to change of stored rules.
      9cbd0c15
  24. 19 Feb, 2007 1 commit
    • 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
  25. 16 Feb, 2007 1 commit
    • Tom Lane's avatar
      Adjust the definition of is_pushed_down so that it's always true for INNER · 8249409b
      Tom Lane authored
      JOIN quals, just like WHERE quals, even if they reference every one of the
      join's relations.  Now that we can reorder outer and inner joins, it's
      possible for such a qual to end up being assigned to an outer join plan node,
      and we mustn't have it treated as a join qual rather than a filter qual for
      the node.  (If it were, the join could produce null-extended rows that it
      shouldn't.)  Per bug report from Pelle Johansson.
      8249409b
  26. 22 Jan, 2007 1 commit
    • Tom Lane's avatar
      Put back planner's ability to cache the results of mergejoinscansel(), · 4f06c688
      Tom Lane authored
      which I had removed in the first cut of the EquivalenceClass rewrite to
      simplify that patch a little.  But it's still important --- in a four-way
      join problem mergejoinscansel() was eating about 40% of the planning time
      according to gprof.  Also, improve the EquivalenceClass code to re-use
      join RestrictInfos rather than generating fresh ones for each join
      considered.  This saves some memory space but more importantly improves
      the effectiveness of caching planning info in RestrictInfos.
      4f06c688
  27. 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
  28. 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
  29. 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
  30. 05 Jan, 2007 1 commit
  31. 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
  32. 04 Oct, 2006 1 commit
  33. 19 Sep, 2006 1 commit
    • Tom Lane's avatar
      Improve usage of effective_cache_size parameter by assuming that all the · b74c5436
      Tom Lane authored
      tables in the query compete for cache space, not just the one we are
      currently costing an indexscan for.  This seems more realistic, and it
      definitely will help in examples recently exhibited by Stefan
      Kaltenbrunner.  To get the total size of all the tables involved, we must
      tweak the handling of 'append relations' a bit --- formerly we looked up
      information about the child tables on-the-fly during set_append_rel_pathlist,
      but it needs to be done before we start doing any cost estimation, so
      push it into the add_base_rels_to_query scan.
      b74c5436
  34. 01 Jul, 2006 1 commit
    • Tom Lane's avatar
      Revise the planner's handling of "pseudoconstant" WHERE clauses, that is · cffd89ca
      Tom Lane authored
      clauses containing no variables and no volatile functions.  Such a clause
      can be used as a one-time qual in a gating Result plan node, to suppress
      plan execution entirely when it is false.  Even when the clause is true,
      putting it in a gating node wins by avoiding repeated evaluation of the
      clause.  In previous PG releases, query_planner() would do this for
      pseudoconstant clauses appearing at the top level of the jointree, but
      there was no ability to generate a gating Result deeper in the plan tree.
      To fix it, get rid of the special case in query_planner(), and instead
      process pseudoconstant clauses through the normal RestrictInfo qual
      distribution mechanism.  When a pseudoconstant clause is found attached to
      a path node in create_plan(), pull it out and generate a gating Result at
      that point.  This requires special-casing pseudoconstants in selectivity
      estimation and cost_qual_eval, but on the whole it's pretty clean.
      It probably even makes the planner a bit faster than before for the normal
      case of no pseudoconstants, since removing pull_constant_clauses saves one
      useless traversal of the qual tree.  Per gripe from Phil Frost.
      cffd89ca
  35. 06 Jun, 2006 1 commit
    • Tom Lane's avatar
      Make the planner estimate costs for nestloop inner indexscans on the basis · 8a30cc21
      Tom Lane authored
      that the Mackert-Lohmann formula applies across all the repetitions of the
      nestloop, not just each scan independently.  We use the M-L formula to
      estimate the number of pages fetched from the index as well as from the table;
      that isn't what it was designed for, but it seems reasonably applicable
      anyway.  This makes large numbers of repetitions look much cheaper than
      before, which accords with many reports we've received of overestimation
      of the cost of a nestloop.  Also, change the index access cost model to
      charge random_page_cost per index leaf page touched, while explicitly
      not counting anything for access to metapage or upper tree pages.  This
      may all need tweaking after we get some field experience, but in simple
      tests it seems to be giving saner results than before.  The main thing
      is to get the infrastructure in place to let cost_index() and amcostestimate
      functions take repeated scans into account at all.  Per my recent proposal.
      
      Note: this patch changes pg_proc.h, but I did not force initdb because
      the changes are basically cosmetic --- the system does not look into
      pg_proc to decide how to call an index amcostestimate function, and
      there's no way to call such a function from SQL at all.
      8a30cc21
  36. 05 Mar, 2006 1 commit
  37. 31 Jan, 2006 1 commit
    • Tom Lane's avatar
      Restructure planner's handling of inheritance. Rather than processing · 8a1468af
      Tom Lane authored
      inheritance trees on-the-fly, which pretty well constrained us to considering
      only one way of planning inheritance, expand inheritance sets during the
      planner prep phase, and build a side data structure that can be consulted
      later to find which RTEs are members of which inheritance sets.  As proof of
      concept, use the data structure to plan joins against inheritance sets more
      efficiently: we can now use indexes on the set members in inner-indexscan
      joins.  (The generated plans could be improved further, but it'll take some
      executor changes.)  This data structure will also support handling UNION ALL
      subqueries in the same way as inheritance sets, but that aspect of it isn't
      finished yet.
      8a1468af
  38. 20 Dec, 2005 1 commit