Re: New vacuum option to do only freezing - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: New vacuum option to do only freezing
Date
Msg-id CAD21AoC3c0R2MMej9dV+ejM4o4zCoOphhXrBmfrTEGyERzTJ5w@mail.gmail.com
Whole thread Raw
In response to Re: New vacuum option to do only freezing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: New vacuum option to do only freezing  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, Jan 12, 2019 at 3:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jan 11, 2019 at 1:14 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > Attached the updated patch. Please review it.
>
> I'm quite confused by this patch.  It seems to me that the easiest way
> to implement this patch would be to (1) make lazy_space_alloc take the
> maxtuples = MaxHeapTuplesPerPage branch when the new option is
> specified, and then (2) forget about them after each page i.e.
>
>         if (nindexes == 0 &&
>             vacrelstats->num_dead_tuples > 0)
>         {
> ...
>         }
>         else if (skipping index cleanup)
>             vacrelstats->num_dead_tuples = 0;
>
> I don't see why it should touch the logic inside lazy_vacuum_page() or
> the decision about whether to truncate.
>

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.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: strange valgrind failures (again)
Next
From: Justin Pryzby
Date:
Subject: Re: unique, partitioned index fails to distinguish index key fromINCLUDEd columns