Re: Freeze avoidance of very large table.
От | Amit Kapila |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CAA4eK1+hJprmwTWG9ZyLpqD4K37PdtZa=VmpBnNf_tE=Y56gYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >>> +#define Anum_pg_class_relallfrozen 12
> >>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it now.
> >>
> >> The relallfrozen would be useful for user to estimate time to vacuum
> >> freeze or anti-wrapping vacuum before being done them actually.
> >> (Also this value is used on regression test.)
> >> But this information is not used on planning like relallvisible, so it
> >> would be good to move this information to another system view like
> >> pg_stat_*_tables.
> >
> > Or make pgstattuple and pgstattuple_approx report even the number
> > of frozen tuples?
> >
>
> But we cannot know the number of frozen pages without installation of
> pageinspect module.
> I'm a bit concerned about that the all projects cannot install
> extentension module into postgresql on production environment.
> I think we need to provide such feature at least into core.
>
>
> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >>> +#define Anum_pg_class_relallfrozen 12
> >>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it now.
> >>
> >> The relallfrozen would be useful for user to estimate time to vacuum
> >> freeze or anti-wrapping vacuum before being done them actually.
> >> (Also this value is used on regression test.)
> >> But this information is not used on planning like relallvisible, so it
> >> would be good to move this information to another system view like
> >> pg_stat_*_tables.
> >
> > Or make pgstattuple and pgstattuple_approx report even the number
> > of frozen tuples?
> >
>
> But we cannot know the number of frozen pages without installation of
> pageinspect module.
> I'm a bit concerned about that the all projects cannot install
> extentension module into postgresql on production environment.
> I think we need to provide such feature at least into core.
>
I think we can display information about relallfrozen it in pg_stat_*_tables
as suggested by you. It doesn't make much sense to keep it in pg_class
unless we have some usecase for the same.
В списке pgsql-hackers по дате отправления: