On Sat, Mar 5, 2016 at 1:25 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers