Re: New vacuum option to do only freezing

On Fri, Nov 9, 2018 at 2:56 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Nov 8, 2018 at 4:36 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > We already have disable_page_skipping option, not (page_skipping
> > false). So ISMT disable_index_cleanup would be more natural.
>
> Sure.
>
> > Also,
> > since what to do with this option is not only skipping vacuum indexes
> > but also skipping removeing dead tuples on heap, I think that the
> > option should have a more understandable name for users indicating
> > that both it removes dead tuples less than the normal vacuum and it's
> > aimed to freeze tuple more faster. Of course we document them, though.
>
> Well, I actually don't think that you should control two behaviors
> with the same option. If you want to vacuum and skip index cleanup,
> you should say VACUUM (disable_index_cleanup). If you want to vacuum,
> disable index cleanup, and skip aggressively, you should say VACUUM
> (freeze, disable_index_cleanup). Both behaviors seem useful.
>

Attached the updated version patch incorporated all comments I got.
The patch includes the following changes.

* Changed the option name to DISABLE_INDEX_CLENAUP. I agreed with
Robert and Nathan, having an option separated from FREEZE.

* Instead of freezing xmax I've changed the behaviour of the new
option (DISABLE_INDEX_CLEANUP) so that it sets dead tuples as dead
instead of as unused and skips both index vacuum and index cleanup.
That is, we remove the storage of dead tuple but leave dead itemids
for the index lookups. These are removed by the next vacuum execution
enabling index cleanup. Currently HOT-pruning doesn't set the root of
the chain as unused even if the whole chain is dead. Since setting
tuples as dead removes storage the freezing xmax is no longer
required.

The second change might conflict with the retail index deletion
patch[1], which makes HOT-pruning *mark* tuples as dead (i.g., using
ItemIdMarkDead() instead). I think that this patch would not block
that patch but I've not considered deeply yet the combination with
these two pathes.

[1] https://www.postgresql.org/message-id/flat/425db134-8bba-005c-b59d-56e50de3b41e%40postgrespro.ru

Regards,

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