| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New vacuum option to do only freezing |
| Date: | 2019-04-16 01:03:03 |
| Message-ID: | CA+TgmoZu+_-q-GFgs6vwKNj-Rs7YJmPPrX+mx5_Drgvr=QZfMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 15, 2019 at 3:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-04-16 01:04:13 | Re: finding changed blocks using WAL scanning |
| Previous Message | Amit Langote | 2019-04-16 00:17:05 | Re: COLLATE: Hash partition vs UPDATE |