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
|
Список | 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 по дате отправления: