On Sat, Mar 5, 2016 at 11:25 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > 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? >
Attached latest version optimisation patch. I'm still consider regarding pg_upgrade regression test code, so I will submit that patch later. Regards, -- Masahiko Sawada
000_optimize_vacuum_using_freezemap_v37.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
