Re: EXPLAIN ANALYZE printing logical and hardware I/O per-node - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: EXPLAIN ANALYZE printing logical and hardware I/O per-node
Date
Msg-id 9362e74e0712162328m3ea21628se928e59ea27c6747@mail.gmail.com
Whole thread Raw
In response to Re: EXPLAIN ANALYZE printing logical and hardware I/O per-node  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
<br /><br /><div class="gmail_quote">On Dec 16, 2007 1:03 AM, Heikki Linnakangas <<a
href="mailto:heikki@enterprisedb.com">heikki@enterprisedb.com</a>>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div
class="Ih2E3d">GokulakannanSomasundaram wrote:<br />> I was going to say that I'm really only interested in physical
I/O.Logical<br />>> I/O which is satisfied by the kernel cache is only marginally interesting <br />>>
and<br/>>> buffer fetches from Postgres's shared buffer is entirely uninteresting<br />>> from<br
/>>>the point of view of trying to figure out what is slowing down a query.<br />><br />> Ok the Physical
I/Osare already visible, if you enable log_statement_stats. <br /><br /></div>I think you missed the point. What
log_statement_statsshows are not<br />physical I/Os, they're read() system calls. Unfortunately there's no<br />direct
wayto tell if a read() is satisfied from OS cache or not. Greg's <br />suggestion was about how to do that.<br
/></blockquote></div><br/>Oh OK. Thanks for clarifying..<br clear="all" /><br />-- <br />Thanks,<br />Gokul.<br
/>CertoSQLProject,<br />Allied Solution Group.<br />(<a href="http://www.alliedgroups.com"> www.alliedgroups.com</a>)  

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Negative LIMIT and OFFSET?
Next
From: NikhilS
Date:
Subject: Re: VLDB Features