Re: New vacuum option to do only freezing

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: New vacuum option to do only freezing
Дата
Msg-id CAD21AoBhwDdM_pbX2M+2K4H5W28Ld++BpMPOjE+OfcoGHJeX=A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New vacuum option to do only freezing  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: New vacuum option to do only freezing  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: "make installcheck" fails in src/test/recovery
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Status of the table access method work