Re: Freeze avoidance of very large table.

On Sat, Mar 5, 2016 at 1:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>>> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
>>>> I think you should commit this. The chances of anyone other than you
>>>> and Masahiko recalling that you developed this tool in 3 years is
>>>> essentially nil. I think that the cost of committing a developer-level
>>>> debugging tool like this is very low. Modules like pg_freespacemap
>>>> currently already have no chance of being of use to ordinary users.
>>>> All you need to do is restrict the functions to throw an error when
>>>> called by non-superusers, out of caution.
>>>>
>>>> It's a problem that modules like pg_stat_statements and
>>>> pg_freespacemap are currently lumped together in the documentation,
>>>> but we all know that.
>>
>>> +1.
>>
>> Would it make any sense to stick it under src/test/modules/ instead of
>> contrib/ ?  That would help make it clear that it's a debugging tool
>> and not something we expect end users to use.
>
> I actually think end-users might well want to use it.  Also, I created
> it by hacking up pg_freespacemap, so it may make sense to have it in
> the same place.
> I would also be tempted to add an additional C functions that scan the
> entire visibility map and return counts of the total number of bits of
> each type that are set, and similarly for the page level bits.
> Presumably that would be much faster than

+1.

>
> I am also tempted to change the API to be a bit more friendly,
> although I am not sure exactly how.  This was a quick and dirty hack
> so that I could test, but the hardest thing about making it not a
> quick and dirty hack is probably deciding on a good UI.
>

Does it mean visibility map API in visibilitymap.c?

Regards,

--
Masahiko Sawada