Re: New vacuum option to do only freezing - Mailing list pgsql-hackers

From Robert Haas
Subject Re: New vacuum option to do only freezing
Date
Msg-id CA+TgmoZu+_-q-GFgs6vwKNj-Rs7YJmPPrX+mx5_Drgvr=QZfMA@mail.gmail.com
Whole thread Raw
In response to Re: New vacuum option to do only freezing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New vacuum option to do only freezing
List pgsql-hackers
On Mon, Apr 15, 2019 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No.  I'm thinking there should be exactly one test of index_cleanup
> in this logic, and what it would be is along the lines of
>
>                     if (HeapTupleIsHotUpdated(&tuple) ||
>                         HeapTupleIsHeapOnly(&tuple) ||
> +                       params->index_cleanup == VACOPT_TERNARY_DISABLED)
>                         nkeep += 1;
>                     else

I'm not sure that's correct.  If you do that, it'll end up in the
non-tupgone case, which might try to freeze a tuple that should've
been removed.  Or am I confused?

My idea of the mechanism of action of this patch is that we accumulate
the tuples just as if we were going to vacuum them, but then at the
end of each page we forget them all, sorta like there are no indexes.
In that mental model, I don't really see why this part of this logic
needs any adjustment at all vs. pre-patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: COLLATE: Hash partition vs UPDATE
Next
From: Robert Haas
Date:
Subject: Re: finding changed blocks using WAL scanning