On 05/06/2011 05:58 PM, Josh Berkus wrote:
Yeah, I wasn't thinking of including all of contrib. There's a lot of
reasons not to do that. I was asking about pgstattuple in particular,
since it's:
(a) small
(b) has no external dependancies
(c) adds no stability risk or performance overhead
(d) is usually needed on production systems when it's needed at all
It's possible that we have one or two other diagnostic utilities which
meet the above profile. pageinspect, maybe?
I use pgstattuple, pageinspect, pg_freespacemap, and pg_buffercache
regularly enough that I wish they were more common. Throw in pgrowlocks
and you've got the whole group Robert put into the debug set. It makes
me sad every time I finish a utility using one of these and realize I'll
have to include the whole "make sure you have the contrib modules
installed" disclaimer in its documentation again.
These are the only ones I'd care about moving into a more likely place.
The rest of the contrib modules are the sort where if you need them, you
realize that early and get them installed. These are different by
virtue of their need popping up most often during emergencies. The fact
that I believe they all match the low impact criteria too makes it even
easier to consider.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
