Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAA4eK1+hJprmwTWG9ZyLpqD4K37PdtZa=VmpBnNf_tE=Y56gYQ@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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.
>

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.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: JDBC driver debug out?
Next
From: Tatsuo Ishii
Date:
Subject: Re: JDBC driver debug out?