On Thu, Feb 19, 2015 at 3:44 PM, Kevin Grittner <kgri...@ymail.com> wrote: >> I'm also interested in handling the case Stephen Frost described, where >> a tuple is effectively dead but we don't currently have the means of >> discovering the fact, because there is an older long running transaction >> which is never in fact going to be able to see the tuple. > > Absolutely. That's one of several other issues that I've been > looking at over the last few weeks. It sounds like people are > already working on that one, which is great. My personal priority > list included that, but after the two I submitted here and a patch > to allow combining near-empty btree pages so that btree bloat is > constrained without having to reindex periodically for the cases > where index tuples are added in index order (at one or a few > insertion points) and most-but-not-all are deleted. You can > currently wind up with a worst-case of one index tuple per page > with no action to reduce that bloat by vacuum processes.
I'd be willing to test that patch. I have a big database that does that, and a script that fills the disk with said bloat. That's forced me to do periodic reindexing, which sucks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
