On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> >> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao <masao.fu...@gmail.com> >> wrote: >> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada <sawada.m...@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. >
I'm thinking a bit about implementing the read-only table that is restricted to update/delete and is ensured that whole table is frozen, if this feature is committed. The value of relallfrozen might be useful for such feature. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
