1. 27 Mar, 2009 11 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 4 commits