Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jan 2, 2014 at 12:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In any case, upon further reflection I'm not convinced that doing this
>> with a SELECT-based query is the right thing, no matter whether the query
>> looks at a function or a system column; because by definition, you'll only
>> be able to see tuples that are visible to your current snapshot. For real
>> forensics work, you need to be able to see all tuples, which makes me
>> think that something akin to pgstattuple is the right API; that is "return
>> a set of the header info for all tuples on such-and-such pages of this
>> relation". That should dodge any performance problem, because the
>> heap_open overhead could be amortized across lots of tuples, and it also
>> sidesteps all problems with adding new system columns.
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
