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

From Masahiko Sawada
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAD21AoC=67JRLd5BAct=dx7MGHNKR3H7R0G-gnzax0xZAx3M6Q@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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.
Thought?

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: run pg_rewind on an uncleanly shut down cluster.
Next
From: Shay Rojansky
Date:
Subject: Re: Odd query execution behavior with extended protocol