On Thu, Jan 2, 2014 at 2:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I both agree and disagree with this. I think that pgstattuple is >> useful, and I further agree that adding a stat to it about how much of >> the heap is frozen would be worthwhile. However, an aggregate number >> isn't always what you want, and being able to scrutinize specific >> tuples is, I think, a useful thing. > > Oh, I guess I referenced the wrong contrib module, because what I was > trying to propose is a function that returns a setof record, one row for > each physical tuple it finds. There are some functions in > contrib/pageinspect that work like that, but not pgstattuple. I don't > think pageinspect's API is ideal because it's tightly tied to processing > one page at a time, but it does show information a bit like what we need > here.
Sure, Álvaro mentioned the same thing upthread. Also, if you notice, the function I was proposing to add does basically the same thing as pageinsect, except one tuple at a time rather than one page at a time. I think both are useful, though. pageinspect is superuser-only, and needing work by pages isn't always convenient. I thought about making the pg_tuple_header() function I proposed scan using SnapshotAny rather than the active snapshot, but then I think it'd need to be superuser-only. I also thought about making it use SnapshotAny for superusers and the active snapshot for everybody else, but that seemed like it could be confusing. We could certainly add a function that returns SETOF record, taking e.g. regclass as an argument, but it doesn't seem a stretch to me to think that you might want to get tuple header information for some but not all tuples in the relation, and I don't see any real good way to tell the function exactly what tuples you want except by invoking it once per TID. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
