1. 31 8月, 2012 13 次提交
  2. 30 8月, 2012 6 次提交
    • R
      Comment fixes. · e1a6375d
      Robert Haas 提交于
      Jeff Davis, somewhat edited by me
      e1a6375d
    • R
      152525b5
    • P
      Also check for Python platform-specific include directory · 9cffb187
      Peter Eisentraut 提交于
      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
    • T
      Adjust definition of cheapest_total_path to work better with LATERAL. · e83bb10d
      Tom Lane 提交于
      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
    • B
      9fe6da5c
    • B
      Report postmaster.pid file as empty if it is empty, rather than · 3825963e
      Bruce Momjian 提交于
      reporting in contains invalid data.
      3825963e
  3. 29 8月, 2012 12 次提交
  4. 28 8月, 2012 9 次提交