I was going to say that I'm really only interested in physical I/O. Logical
I/O which is satisfied by the kernel cache is only marginally interesting and
buffer fetches from Postgres's shared buffer is entirely uninteresting from
the point of view of trying to figure out what is slowing down a query.
Ok the Physical I/Os are already visible, if you enable log_statement_stats. Again i accept that it would be more helpful, if it gets displayed with Explain Analyze.
However I suppose that's not true. There are other reasons why buffer fetches
could be interesting. In particular I imagine when users post explain analyzes
it would give us a good idea of whether their tables or bloated or their
tuples are extremely wide (in cases where the planner gets it wrong).
I have used it a lot for query tuning. If we re-write a query in such a way, the logical reads will come down, then it implies lesser physical reads in production. I think you would accept that there are some ways in which the query can be re-written only by humans and not by the optimizer. When we do that, instead of looking at the explain analyze time, it makes more sense for me to look at the logical reads
But I do think that showing logical I/Os without even an heuristic based
measurement of actual physical i/o is pretty useless. It will make people
think they want to grow their shared buffers to cover all of memory.
I just want to clarify that we should display both Logical reads and physical reads together. But increasing the shared buffer by looking at the performance of a query doesn't seem to be a good idea. But people should be aware that Logical reads is not for shared buffer management.
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(
www.alliedgroups.com)
