Re: contrib/pg_stat_statements 1226

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 2. I'm unconvinced by the proposed changes to accumulate backend-local
> I/O counters, too. The fact of the matter is that those counters are
> left over from Berkeley days, a time when PG hackers tended to do their
> performance measurements in standalone backends (!). They're obviously
> not the full story now on write measurements, and I don't have any
> confidence in them as read measurements either, particularly seeing that
> the wave of the future is likely to be asynchronous read operations
> (with the posix_fadvise patch and foreseeable follow-on work). I think
> those counters should more likely be done away with than
> institutionalized in EXPLAIN ANALYZE output. You can get more reliable
> information about what's happening from the existing pgstats system-wide
> I/O counts.

It's clear that these counters are not the whole picture. But I think that
just means we need more counters with more sources of data, not that we need
to get rid of the ones we have. There's no reason we shouldn't have counters
for advised buffers along with reads.

I'm also picturing using dtrace to find out how many reads were satisfied from
cache and how many required physical reads for example.

The system-wide stats satisfy a very different need from this. The sysadmin or
DBA might want to know about system-wide stats but a programmer or a DBA
analyzing a specific query needs to know what that query is doing.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!