From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow "snapshot too old" error, to prevent bloat |
Date: | 2015-02-19 18:54:27 |
Message-ID: | CAGTBQpZbOgv-d5rA0mRO+XYpP1cBRC9MYuFSJfPCn-Bxc9Lhjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 19, 2015 at 3:44 PM, Kevin Grittner <kgrittn(at)ymail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-02-19 18:54:35 | Re: Allow "snapshot too old" error, to prevent bloat |
Previous Message | David Fetter | 2015-02-19 18:51:30 | Re: POLA violation with \c service= |