1. 30 Aug, 2012 19 commits
    • Bruce Momjian's avatar
      1fbc30f1
    • Bruce Momjian's avatar
      Document that max_locks_per_transaction might need to be increased for · 39b42ecb
      Bruce Momjian authored
      queries on parent tables, per suggestion from Josh Berkus.
      39b42ecb
    • Alvaro Herrera's avatar
      Split tuple struct defs from htup.h to htup_details.h · c219d9b0
      Alvaro Herrera authored
      This reduces unnecessary exposure of other headers through htup.h, which
      is very widely included by many files.
      
      I have chosen to move the function prototypes to the new file as well,
      because that means htup.h no longer needs to include tupdesc.h.  In
      itself this doesn't have much effect in indirect inclusion of tupdesc.h
      throughout the tree, because it's also required by execnodes.h; but it's
      something to explore in the future, and it seemed best to do the htup.h
      change now while I'm busy with it.
      c219d9b0
    • Bruce Momjian's avatar
      Remove configure flag --disable-shared, as it is no longer used by any · 381a9ed6
      Bruce Momjian authored
      port.  The last use was QNX, per Peter Eisentraut.
      381a9ed6
    • Robert Haas's avatar
      9bedfbd0
    • Bruce Momjian's avatar
      Document that log_autovacuum_min_duration can be used to monitor · 83fbfec3
      Bruce Momjian authored
      autovacuum activity.
      
      Per report from Marc Mamin
      83fbfec3
    • Tom Lane's avatar
      Suppress creation of backwardly-indexed paths for LATERAL join clauses. · 77387f0a
      Tom Lane authored
      Given a query such as
      
      SELECT * FROM foo JOIN LATERAL (SELECT foo.var1) ss(x) ON ss.x = foo.var2
      
      the existence of the join clause "ss.x = foo.var2" encourages indxpath.c to
      build a parameterized path for foo using any index available for foo.var2.
      This is completely useless activity, though, since foo has got to be on the
      outside not the inside of any nestloop join with ss.  It's reasonably
      inexpensive to add tests that prevent creation of such paths, so let's do
      that.
      77387f0a
    • Robert Haas's avatar
      Document how to prevent PostgreSQL itself from exhausting memory. · 35738b59
      Robert Haas authored
      The existing documentation in Linux Memory Overcommit seemed to
      assume that PostgreSQL itself could never be the problem, or at
      least it didn't tell you what to do about it.
      
      Per discussion with Craig Ringer and Kevin Grittner.
      35738b59
    • Heikki Linnakangas's avatar
      Fix division by zero in the new range type histogram creation. · 3e6eb0dd
      Heikki Linnakangas authored
      Report and analysis by Matthias.
      3e6eb0dd
    • Robert Haas's avatar
      Add missing period to detail message. · a66fca3f
      Robert Haas authored
      Per note from Peter Eisentraut.
      a66fca3f
    • Robert Haas's avatar
      Document that COPY OUT requires an absolute pathname. · b9ea8d20
      Robert Haas authored
      As suggested by Etsuro Fujita, but with somewhat different wording.
      b9ea8d20
    • Bruce Momjian's avatar
    • Robert Haas's avatar
      Fix logic bug in gistchoose and gistRelocateBuildBuffersOnSplit. · c8ba697a
      Robert Haas authored
      Every time the best-tuple-found-so-far changes, we need to reset all
      the penalty values in which_grow[] to the penalties for the new best
      tuple.  The old code failed to do this, resulting in inferior index
      quality.
      
      The original patch from Alexander Korotkov was just two lines; I took
      the liberty of fleshing that out by adding a bunch of comments that I
      hope will make this logic easier for others to understand than it was
      for me.
      c8ba697a
    • Tom Lane's avatar
      Improve EXPLAIN's ability to cope with LATERAL references in plans. · d1a4db8d
      Tom Lane authored
      push_child_plan/pop_child_plan didn't bother to adjust the "ancestors"
      list of parent plan nodes when descending to a child plan node.  I think
      this was okay when it was written, but it's not okay in the presence of
      LATERAL references, since a subplan node could easily be returning a
      LATERAL value back up to the same nestloop node that provides the value.
      Per changed regression test results, the omission led to failure to
      interpret Param nodes that have perfectly good interpretations.
      d1a4db8d
    • Robert Haas's avatar
      Comment fixes. · e1a6375d
      Robert Haas authored
      Jeff Davis, somewhat edited by me
      e1a6375d
    • Robert Haas's avatar
    • Peter Eisentraut's avatar
      Also check for Python platform-specific include directory · 9cffb187
      Peter Eisentraut authored
      Python can be built to have two separate include directories: one for
      platform-independent files and one for platform-specific files.  So
      far, this has apparently never mattered for a PL/Python build.  But
      with the new multi-arch Python packages in Debian and Ubuntu, this is
      becoming the standard configuration on these platforms, so we must
      check these directories separately to be able to build there.
      
      Also add a bit of reporting in configure to be able to see better what
      is going on with this.
      9cffb187
    • Tom Lane's avatar
      Adjust definition of cheapest_total_path to work better with LATERAL. · e83bb10d
      Tom Lane authored
      In the initial cut at LATERAL, I kept the rule that cheapest_total_path
      was always unparameterized, which meant it had to be NULL if the relation
      has no unparameterized paths.  It turns out to work much more nicely if
      we always have *some* path nominated as cheapest-total for each relation.
      In particular, let's still say it's the cheapest unparameterized path if
      there is one; if not, take the cheapest-total-cost path among those of
      the minimum available parameterization.  (The first rule is actually
      a special case of the second.)
      
      This allows reversion of some temporary lobotomizations I'd put in place.
      In particular, the planner can now consider hash and merge joins for
      joins below a parameter-supplying nestloop, even if there aren't any
      unparameterized paths available.  This should bring planning of
      LATERAL-containing queries to the same level as queries not using that
      feature.
      
      Along the way, simplify management of parameterized paths in add_path()
      and friends.  In the original coding for parameterized paths in 9.2,
      I tried to minimize the logic changes in add_path(), so it just treated
      parameterization as yet another dimension of comparison for paths.
      We later made it ignore pathkeys (sort ordering) of parameterized paths,
      on the grounds that ordering isn't a useful property for the path on the
      inside of a nestloop, so we might as well get rid of useless parameterized
      paths as quickly as possible.  But we didn't take that reasoning as far as
      we should have.  Startup cost isn't a useful property inside a nestloop
      either, so add_path() ought to discount startup cost of parameterized paths
      as well.  Having done that, the secondary sorting I'd implemented (in
      add_parameterized_path) is no longer needed --- any parameterized path that
      survives add_path() at all is worth considering at higher levels.  So this
      should be a bit faster as well as simpler.
      e83bb10d
    • Bruce Momjian's avatar
      9fe6da5c
  2. 29 Aug, 2012 4 commits
  3. 28 Aug, 2012 14 commits
  4. 27 Aug, 2012 3 commits