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)

Reply via email to