1. 27 Mar, 2009 7 commits
  2. 26 Mar, 2009 12 commits
  3. 25 Mar, 2009 9 commits
  4. 24 Mar, 2009 4 commits
    • Tom Lane's avatar
      Install a search tree depth limit in GIN bulk-insert operations, to prevent · e5efda44
      Tom Lane authored
      them from degrading badly when the input is sorted or nearly so.  In this
      scenario the tree is unbalanced to the point of becoming a mere linked list,
      so insertions become O(N^2).  The easiest and most safely back-patchable
      solution is to stop growing the tree sooner, ie limit the growth of N.  We
      might later consider a rebalancing tree algorithm, but it's not clear that
      the benefit would be worth the cost and complexity.  Per report from Sergey
      Burladyan and an earlier complaint from Heikki.
      
      Back-patch to 8.2; older versions didn't have GIN indexes.
      e5efda44
    • Tom Lane's avatar
    • Tom Lane's avatar
      Implement "fastupdate" support for GIN indexes, in which we try to accumulate · ff301d6e
      Tom Lane authored
      multiple index entries in a holding area before adding them to the main index
      structure.  This helps because bulk insert is (usually) significantly faster
      than retail insert for GIN.
      
      This patch also removes GIN support for amgettuple-style index scans.  The
      API defined for amgettuple is difficult to support with fastupdate, and
      the previously committed partial-match feature didn't really work with
      it either.  We might eventually figure a way to put back amgettuple
      support, but it won't happen for 8.4.
      
      catversion bumped because of change in GIN's pg_am entry, and because
      the format of GIN indexes changed on-disk (there's a metapage now,
      and possibly a pending list).
      
      Teodor Sigaev
      ff301d6e
    • Peter Eisentraut's avatar
      Fix my typo · 9987f660
      Peter Eisentraut authored
      9987f660
  5. 23 Mar, 2009 6 commits
  6. 22 Mar, 2009 2 commits
    • Tom Lane's avatar
      Add isExtend to the parameters of the buffer_read_start and buffer_read_done · 44023dc5
      Tom Lane authored
      DTrace probes, so that ordinary reads can be distinguished from relation
      extension operations.  Move buffer_read_start probe to before the
      smgrnblocks() call that's needed in the isExtend case, since really that step
      should be charged as part of the time needed for the extension operation.
      (This makes it slightly harder to match the read_start with the associated
      read_done, since now you can't match them on blockNumber, but it should still
      be possible since isExtend operations on the same relation can never be
      interleaved.)  Per recent discussion.
      
      In passing, add the page identity (forkNum/blockNum) to the parameters of the
      buffer_flush_start/buffer_flush_done probes, which were unaccountably lacking
      the info.
      44023dc5
    • Bruce Momjian's avatar
      Clarify 'cert' authentication documention. · f04ee704
      Bruce Momjian authored
      f04ee704