Re: New vacuum option to do only freezing

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: New vacuum option to do only freezing
Дата
Msg-id CA+TgmoZu+_-q-GFgs6vwKNj-Rs7YJmPPrX+mx5_Drgvr=QZfMA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New vacuum option to do only freezing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: New vacuum option to do only freezing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: COLLATE: Hash partition vs UPDATE
Следующее
От: Robert Haas
Дата:
Сообщение: Re: finding changed blocks using WAL scanning