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. > > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's PostGIS support! > -- Thanks, Gokul. CertoSQL Project, Allied Solution Group. (www.alliedgroups.com)
