1. 29 10月, 2008 1 次提交
    • T
      Change WorkTableScan to not support backward scan. The apparent support · a80a1224
      Tom Lane 提交于
      didn't actually work, because nodeRecursiveunion.c creates the underlying
      tuplestore with backward scan disabled; which is a decision that we shouldn't
      reverse because of performance cost.  We could imagine adding signaling from
      WorkTableScan to RecursiveUnion about whether backward scan is needed ...
      but in practice it'd be a waste of effort, because there simply isn't any
      current or plausible future scenario where WorkTableScan would be called on
      to scan backward.  So just dike out the code that claims to support it.
      a80a1224
  2. 28 10月, 2008 7 次提交
  3. 27 10月, 2008 5 次提交
  4. 26 10月, 2008 3 次提交
    • T
      Better solution to the IN-list issue: instead of having an arbitrary cutoff, · 0aed62fe
      Tom Lane 提交于
      treat Var and non-Var IN-list items differently.  Only non-Var items are
      candidates to go into an ANY(ARRAY) construct --- we put all Vars as separate
      OR conditions on the grounds that that leaves more scope for optimization.
      Per suggestion from Robert Haas.
      0aed62fe
    • T
      Be a little smarter about qual handling for semi-joins: a qual that mentions · aa0fb530
      Tom Lane 提交于
      only the outer side can be pushed down rather than having to be evaluated
      at the join.
      aa0fb530
    • T
      Add a heuristic to transformAExprIn() to make it prefer expanding "x IN (list)" · ddbe8dca
      Tom Lane 提交于
      into an OR of equality comparisons, rather than x = ANY(ARRAY[...]), when there
      are Vars in the right-hand side.  This avoids a performance regression compared
      to pre-8.2 releases, in cases where the OR form can be optimized into scans
      of multiple indexes.  Limit the possible downside by preferring this form only
      when the list isn't very long (I set the cutoff at 32 elements, which is a
      bit arbitrary but in the right ballpark).  Per discussion with Jim Nasby.
      
      In passing, also make it try the OR form if it cannot select a common type
      for the array elements; we've seen a complaint or two about how the OR form
      worked for such cases and ARRAY doesn't.
      ddbe8dca
  5. 25 10月, 2008 1 次提交
    • T
      Reduce the memory footprint of large pending-trigger-event lists, as per my · 312b1a98
      Tom Lane 提交于
      recent proposal.  In typical cases, we now need 12 bytes per insert or delete
      event and 16 bytes per update event; previously we needed 40 bytes per
      event on 32-bit hardware and 80 bytes per event on 64-bit hardware.  Even
      in the worst case usage pattern with a large number of distinct triggers being
      fired in one query, usage is at most 32 bytes per event.  It seems to be a
      bit faster than the old code as well, due to reduction of palloc overhead.
      
      This commit doesn't address the TODO item of allowing the event list to spill
      to disk; rather it's trying to stave off the need for that.  However, it
      probably makes that task a bit easier by reducing the data structure's
      dependency on pointers.  It would now be practical to dump an event list to
      disk by "chunks" instead of individual events.
      312b1a98
  6. 24 10月, 2008 5 次提交
  7. 23 10月, 2008 7 次提交
  8. 22 10月, 2008 3 次提交
    • T
      Fix GiST's killing tuple: GISTScanOpaque->curpos wasn't · b9856b67
      Teodor Sigaev 提交于
      correctly set. As result, killtuple() marks as dead
      wrong tuple on page. Bug was introduced by me while fixing
      possible duplicates during GiST index scan.
      b9856b67
    • P
      SQL:2008 alternative syntax for LIMIT/OFFSET: · 361bfc35
      Peter Eisentraut 提交于
      OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
      361bfc35
    • T
      Add a concept of "placeholder" variables to the planner. These are variables · e6ae3b5d
      Tom Lane 提交于
      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
  9. 21 10月, 2008 7 次提交
  10. 20 10月, 2008 1 次提交