From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New vacuum option to do only freezing |
Date: | 2019-01-15 20:24:44 |
Message-ID: | CA+TgmoagE-6k05tp+yzyV2YBgSCiTr=yqQfGrKvTudZoTQ24XQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 14, 2019 at 9:24 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> I think that because the tuples that got dead after heap_page_prune()
> looked are recorded but not removed without lazy_vacuum_page() we need
> to process them in lazy_vacuum_page(). For decision about whether to
> truncate we should not change it, so I will fix it. It should be an
> another option to control whether to truncate if we want.
I think that heap_page_prune() is going to truncate dead tuples to
dead line pointers. At that point the tuple is gone. The only
remaining step is to mark the dead line pointer as unused, which can't
be done without scanning the indexes. So I don't understand what
lazy_vacuum_page() would need to do in this case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-15 20:33:07 | Re: MERGE SQL statement for PG12 |
Previous Message | Robert Haas | 2019-01-15 20:21:18 | Re: Connection slots reserved for replication |