Re: EXPLAIN ANALYZE printing logical and hardware I/O per-node

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>
Cc: "Neil Conway" <neilc(at)samurai(dot)com>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXPLAIN ANALYZE printing logical and hardware I/O per-node
Date: 2007-12-15 09:27:59
Message-ID: 87odcsqpcw.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> writes:

> Hi,
> I already made a discussion about it. We can view the Logical I/Os. If
> we enable the log_statement_stats in the conf file and apply the following
> patch, it is possible. But putting it in Explain analyze makes more sense to
> me.

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.

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).

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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-12-15 09:28:53 Re: Negative LIMIT and OFFSET?
Previous Message Simon Riggs 2007-12-15 09:14:16 Re: VLDB Features