Skip to content
Snippets Groups Projects
  1. Jun 07, 2012
  2. Oct 01, 2011
    • Tom Lane's avatar
      Support GiST index support functions that want to cache data across calls. · d22a09dc
      Tom Lane authored
      pg_trgm was already doing this unofficially, but the implementation hadn't
      been thought through very well and leaked memory.  Restructure the core
      GiST code so that it actually works, and document it.  Ordinarily this
      would have required an extra memory context creation/destruction for each
      GiST index search, but I was able to avoid that in the normal case of a
      non-rescanned search by finessing the handling of the RBTree.  It used to
      have its own context always, but now shares a context with the
      scan-lifespan data structures, unless there is more than one rescan call.
      This should make the added overhead unnoticeable in typical cases.
      d22a09dc
  3. Sep 08, 2011
    • Heikki Linnakangas's avatar
      Buffering GiST index build algorithm. · 5edb24a8
      Heikki Linnakangas authored
      When building a GiST index that doesn't fit in cache, buffers are attached
      to some internal nodes in the index. This speeds up the build by avoiding
      random I/O that would otherwise be needed to traverse all the way down the
      tree to the find right leaf page for tuple.
      
      Alexander Korotkov
      5edb24a8
  4. May 31, 2011
    • Tom Lane's avatar
      Protect GIST logic that assumes penalty values can't be negative. · 6923d699
      Tom Lane authored
      Apparently sane-looking penalty code might return small negative values,
      for example because of roundoff error.  This will confuse places like
      gistchoose().  Prevent problems by clamping negative penalty values to
      zero.  (Just to be really sure, I also made it force NaNs to zero.)
      Back-patch to all supported branches.
      
      Alexander Korotkov
      6923d699
  5. Dec 23, 2010
    • Heikki Linnakangas's avatar
      Rewrite the GiST insertion logic so that we don't need the post-recovery · 9de3aa65
      Heikki Linnakangas authored
      cleanup stage to finish incomplete inserts or splits anymore. There was two
      reasons for the cleanup step:
      
      1. When a new tuple was inserted to a leaf page, the downlink in the parent
      needed to be updated to contain (ie. to be consistent with) the new key.
      Updating the parent in turn might require recursively updating the parent of
      the parent. We now handle that by updating the parent while traversing down
      the tree, so that when we insert the leaf tuple, all the parents are already
      consistent with the new key, and the tree is consistent at every step.
      
      2. When a page is split, we need to insert the downlink for the new right
      page(s), and update the downlink for the original page to not include keys
      that moved to the right page(s). We now handle that by setting a new flag,
      F_FOLLOW_RIGHT, on the non-rightmost pages in the split. When that flag is
      set, scans always follow the rightlink, regardless of the NSN mechanism used
      to detect concurrent page splits. That way the tree is consistent right after
      split, even though the downlink is still missing. This is very similar to the
      way B-tree splits are handled. When the downlink is inserted in the parent,
      the flag is cleared. To keep the insertion algorithm simple, when an
      insertion sees an incomplete split, indicated by the F_FOLLOW_RIGHT flag, it
      finishes the split before doing anything else.
      
      These changes allow removing the whole "invalid tuple" mechanism, but I
      retained the scan code to still follow invalid tuples correctly. While we
      don't create any such tuples anymore, we want to handle them gracefully in
      case you pg_upgrade a GiST index that has them. If we encounter any on an
      insert, though, we just throw an error saying that you need to REINDEX.
      
      The issue that got me into doing this is that if you did a checkpoint while
      an insert or split was in progress, and the checkpoint finishes quickly so
      that there is no WAL record related to the insert between RedoRecPtr and the
      checkpoint record, recovery from that checkpoint would not know to finish
      the incomplete insert. IOW, we have the same issue we solved with the
      rm_safe_restartpoint mechanism during normal operation too. It's highly
      unlikely to happen in practice, and this fix is far too large to backpatch,
      so we're just going to live with in previous versions, but this refactoring
      fixes it going forward.
      
      With this patch, you don't get the annoying
      'index "FOO" needs VACUUM or REINDEX to finish crash recovery' notices
      anymore if you crash at an unfortunate moment.
      9de3aa65
  6. Dec 04, 2010
  7. Sep 20, 2010
  8. Aug 17, 2010
  9. Jun 12, 2009
  10. Apr 14, 2008
    • Tom Lane's avatar
      Push index operator lossiness determination down to GIST/GIN opclass · 9b5c8d45
      Tom Lane authored
      "consistent" functions, and remove pg_amop.opreqcheck, as per recent
      discussion.  The main immediate benefit of this is that we no longer need
      8.3's ugly hack of requiring @@@ rather than @@ to test weight-using tsquery
      searches on GIN indexes.  In future it should be possible to optimize some
      other queries better than is done now, by detecting at runtime whether the
      index match is exact or not.
      
      Tom Lane, after an idea of Heikki's, and with some help from Teodor.
      9b5c8d45
  11. Nov 14, 2007
  12. Jan 31, 2007
    • Bruce Momjian's avatar
      Update documentation on may/can/might: · a134ee33
      Bruce Momjian authored
      Standard English uses "may", "can", and "might" in different ways:
      
              may - permission, "You may borrow my rake."
      
              can - ability, "I can lift that log."
      
              might - possibility, "It might rain today."
      
      Unfortunately, in conversational English, their use is often mixed, as
      in, "You may use this variable to do X", when in fact, "can" is a better
      choice.  Similarly, "It may crash" is better stated, "It might crash".
      
      Also update two error messages mentioned in the documenation to match.
      a134ee33
  13. Oct 23, 2006
  14. Mar 10, 2006
  15. Nov 07, 2005
  16. Nov 05, 2005
  17. Oct 21, 2005
  18. Jul 02, 2005
  19. Jun 29, 2005
  20. Jun 20, 2005
  21. May 17, 2005
    • Neil Conway's avatar
      GiST improvements: · eda6dd32
      Neil Conway authored
      - make sure we always invoke user-supplied GiST methods in a short-lived
        memory context. This means the backend isn't exposed to any memory leaks
        that be in those methods (in fact, it is probably a net loss for most
        GiST methods to bother manually freeing memory now). This also means
        we can do away with a lot of ugly manual memory management in the
        GiST code itself.
      
      - keep the current page of a GiST index scan pinned, rather than doing a
        ReadBuffer() for each tuple produced by the scan. Since ReadBuffer() is
        expensive, this is a perf. win
      
      - implement dead tuple killing for GiST indexes (which is easy to do, now
        that we keep a pin on the current scan page). Now all the builtin indexes
        implement dead tuple killing.
      
      - cleanup a lot of ugly code in GiST
      eda6dd32
  22. Apr 09, 2005
  23. Mar 31, 2005
  24. Jan 08, 2005
  25. Nov 29, 2003
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  26. Oct 31, 2003
  27. Sep 29, 2003
  28. Jan 09, 2002
  29. Nov 21, 2001
  30. Oct 13, 2001
  31. May 17, 2001
  32. Jan 24, 2001
  33. Dec 22, 2000
  34. Dec 29, 1998
  35. Jul 29, 1998
  36. Apr 04, 1998
  37. Mar 01, 1998
Loading