- Jun 07, 2012
-
-
Peter Eisentraut authored
-
- Oct 01, 2011
-
-
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.
-
- Sep 08, 2011
-
-
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
-
- May 31, 2011
-
-
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
-
- Dec 23, 2010
-
-
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.
-
- Dec 04, 2010
-
-
Tom Lane authored
-
- Sep 20, 2010
-
-
Magnus Hagander authored
-
- Aug 17, 2010
-
-
Peter Eisentraut authored
-
- Jun 12, 2009
-
-
Tom Lane authored
Dimitri Fontaine
-
- Apr 14, 2008
-
-
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.
-
- Nov 14, 2007
-
-
Tom Lane authored
-
- Jan 31, 2007
-
-
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.
-
- Oct 23, 2006
-
-
Peter Eisentraut authored
-
- Mar 10, 2006
-
-
Bruce Momjian authored
-
- Nov 07, 2005
-
-
Tom Lane authored
-
- Nov 05, 2005
-
-
Peter Eisentraut authored
-
- Oct 21, 2005
- Jul 02, 2005
-
-
Bruce Momjian authored
Christopher Kings-Lynne
-
- Jun 29, 2005
-
-
Bruce Momjian authored
Victor Y. Yegorov
-
- Jun 20, 2005
-
-
Tom Lane authored
-
- May 17, 2005
-
-
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
-
- Apr 09, 2005
-
-
Bruce Momjian authored
we can put words in ulink and the URL will still be printed. per Peter
-
- Mar 31, 2005
-
-
Bruce Momjian authored
-
- Jan 08, 2005
-
-
Tom Lane authored
-
- Nov 29, 2003
-
-
PostgreSQL Daemon authored
$Header: -> $PostgreSQL Changes ...
-
- Oct 31, 2003
-
-
Tom Lane authored
Christopher Kings-Lynne
-
- Sep 29, 2003
-
-
Bruce Momjian authored
arch-dev.sgml Neil Conway
-
- Jan 09, 2002
-
-
Peter Eisentraut authored
And listing QNX 6 as both supported and unsupported is probably not helpful.
-
- Nov 21, 2001
-
-
Thomas G. Lockhart authored
Fix up references to "PostgreSQL" rather than "Postgres". Was roughly evenly split between the two before. ref/ files not yet done.
-
- Oct 13, 2001
-
-
Bruce Momjian authored
-
- May 17, 2001
-
-
Peter Eisentraut authored
-
- Jan 24, 2001
-
-
Bruce Momjian authored
-
- Dec 22, 2000
-
-
Peter Eisentraut authored
-
- Dec 29, 1998
-
-
Thomas G. Lockhart authored
of Norm's Modular Style Sheets and jade/docbook. From Vince Vielhaber <vev@michvhf.com>.
-
- Jul 29, 1998
-
-
Thomas G. Lockhart authored
to be meaningful.
-
- Apr 04, 1998
-
-
Thomas G. Lockhart authored
Add more URL links for GiST information.
-
- Mar 01, 1998
-
-
Thomas G. Lockhart authored
-
Thomas G. Lockhart authored
-