Re: Freeze avoidance of very large table.

On Wed, Aug 19, 2015 at 1:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 18, 2015 at 7:27 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> I have encountered the much cases where pg_stat_statement,
>> pgstattuples are required in production, so I basically agree with
>> moving such extension into core.
>> But IMO, the diagnostic tools for visibility map, heap (pageinspect)
>> and so on, are a kind of debugging tool.
>
> Just because something might be required in production isn't a
> sufficient reason to put it in core. Debugging tools, or anything
> else, can be required in production, too.
>
>> Attached latest v11 patches, which is separated into 2 patches: frozen
>> bit patch and diagnostic function patch.
>> Moving diagnostic function into core is still under the discussion,
>> but this patch puts such function into core because the diagnostic
>> function for visibility map needs to be in core to execute regression
>> test at least.
>
> As has been discussed recently, there are other ways to handle that.

The currently regression test for VM is that we just compare between
the total number of all-visible and all-frozen in VM before and after
VACUUM, and don't check particular a bit in VM.
we could substitute it to the ANALYZE command with enough sampling
number and checking pg_class.relallvisible and pg_class.relallfrozen.

So another way is that diagnostic function for VM is put into
something contrib (pg_freespacemap or pageinspect), and if we want to
use such function in production, we can install such extension as in
the past.

Regards,

--
Masahiko Sawada