Tom Lane <t...@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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
