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 CAD21AoBhwDdM_pbX2M+2K4H5W28Ld++BpMPOjE+OfcoGHJeX=A@mail.gmail.com
Whole thread Raw
In response to Re: New vacuum option to do only freezing  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: New vacuum option to do only freezing
List pgsql-hackers
On Thu, Apr 18, 2019 at 4:20 AM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Wed, Apr 17, 2019 at 10:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Yeah, if we wanted to expose these complications more directly, we
> > could think about adding or changing the main counters.  I was wondering
> > about whether we should have it report "x bytes and y line pointers
> > freed", rather than counting tuples per se.
>

It looks good idea to me.

> I like that idea, but I'm pretty sure that there are very few users
> that are aware of these distinctions at all. It would be a good idea
> to clearly document them.

I completely agreed. I'm sure that only a few user can do the action
of enabling index cleanup when the report says there are many dead
line pointers in the table.

It brought me an another idea of reporting something like "x bytes
freed, y bytes can be freed after index cleanup". That is, we report
how much bytes including tuples and line pointers we freed and how
much bytes of line pointers can be freed after index cleanup. While
index cleanup is enabled, the latter value should always be 0. If the
latter value gets large user can be aware of necessity of doing index
cleanup.

Regards,

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: "make installcheck" fails in src/test/recovery
Next
From: Simon Riggs
Date:
Subject: Re: Status of the table access method work