Re: New vacuum option to do only freezing

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

In response to

Responses

Browse pgsql-hackers by date

  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