On 28 November 2017 at 23:17, Peter Geoghegan wrote:
> BTW, a good short term solution for you might be to change the vacuum
> cost delay settings. They're pretty conservative by default.
>
> There is a good chance that your indexes are mostly in memory even on
> large tables, and B-Tree indexes a
On Tue, Nov 28, 2017 at 1:36 PM, Feike Steenbergen
wrote:
> On a server with a very frequent xid wraparound I can see that the
> anti-wraparound vacuum is finished very quickly with the heap, yet it still
> scans all the indexes, which causes it to still have to read a lot of data,
> which takes a
On Tue, Nov 28, 2017 at 1:55 PM, Tom Lane wrote:
> It might be okay to put such a short-circuit in at a lower level,
> eg within the btree AM. I don't remember at the moment whether
> a btree vacuum scan accomplishes anything much if there are no dead
> tuples.
>
> One thing that I think it does
Feike Steenbergen writes:
> On a server with a very frequent xid wraparound I can see that the
> anti-wraparound vacuum is finished very quickly with the heap, yet it still
> scans all the indexes, which causes it to still have to read a lot of data,
> which takes a considerable amount of time.
>
On 28 November 2017 at 22:48, Peter Geoghegan wrote:
> There is a patch in the ongoing CF to do this:
Ah, thanks, I'll probably review that one then
> It's a lot harder to do this correctly than it first appears.
I already thought my naive approach would not suffice
On Tue, Nov 28, 2017 at 1:36 PM, Feike Steenbergen
wrote:
> On a server with a very frequent xid wraparound I can see that the
> anti-wraparound vacuum is finished very quickly with the heap, yet it still
> scans all the indexes, which causes it to still have to read a lot of data,
> which takes a
Sorry, I didn't attach a good patch, this one should be better
0002-skip_cleanup_for_stale_relation.patch
Description: Binary data
On a server with a very frequent xid wraparound I can see that the
anti-wraparound vacuum is finished very quickly with the heap, yet it still
scans all the indexes, which causes it to still have to read a lot of data,
which takes a considerable amount of time.
I dove into the code a bit and as fa
