Re: Freeze avoidance of very large table.

On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
> wrote:
>>
>> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
>> wrote:
>> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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