Tom Lane <tgl@sss.pgh.pa.us> writes:
> No, I think you misunderstood me entirely. The reason that I rejected
> those parts of the patch is that I think the statistics that are
> available are wrong/useless. If the bufmgr.c counters were really good
> for something they'd have been exposed long since (and we'd probably
> never have built a lot of the other stats collection infrastructure).
The collective stats across the whole cluster and the individual stats for a
specific query broken down by plan node are complementary. Depending on the
circumstance people sometimes need each.
I actually also wrote a patch exposing this same data. I think the bufmgr
counters are flawed but still useful. Just as an example think of how often
you have to explain why a sequential scan of a small table can be faster than
an index scan. Seeing the index scan actually require more logical buffer
fetches than a sequential scan would go a long way to clearing up that
confusion. Better yet, users would be in a position to see whether the planner
is actually estimating i/o costs accurately.
> The EXPLAIN ANALYZE code you submitted is actually kinda cute, and
> I'd have had no problem with it if I thought it were displaying
> numbers that were useful and unlikely to be obsoleted in future
> releases. The work that needs to be done is on collecting the
> numbers more than displaying them.
I agree that we need more data -- my favourite direction is to use a
programmatic interface to dtrace to find out how many buffer reads are
satisfied from filesystem cache and how many from physical reads. But when we
do that doesn't obviate the need for these stats, it would enhance them. You
would get a clear view of how many buffer fetches were satisfied from shared
buffers, filesystem cache, and physical reads.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
