On Thu, Jan 2, 2014 at 2:03 PM, Tom Lane <tgl@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