Greg,
Gregory Stark wrote:
I don't think DTrace is overkill either. The programmatic interface is
undocumented (but I've gotten Sun people to admit it exists -- I just have to
reverse engineer it from the existing code samples) but should be more or less
exactly what we need.
You probably
Decibel! [EMAIL PROTECTED] writes:
Also, has anyone looked into adding a class of system calls that would
actually tell us if the kernel issued physical IO? I find it hard to believe
that other RDBMSes wouldn't like to have that info...
Yeah, I think that's called DTrace
--
Gregory
Decibel! [EMAIL PROTECTED] writes:
When a read() call returns, surely the kernel knows whether it actually
issued
a physical read request to satisfy that. I don't see any reason why you
couldn't have a version of read() that returns that information. I also
rather
doubt that we're the
On Dec 14, 2007, at 11:10 PM, Neil Conway wrote:
But it occurred to me just now that the hardware instruction
counter available
on just about every platform would be good enough for a heuristic
guess at
whether the read(2) was cached.
I'm skeptical that this would be reliable enough to be
On Mon, 17 Dec 2007, Decibel! wrote:
Someone want to throw together some code that actually measures this? Maybe
something that keeps a histogram of how many instructions take place per I/O
request? If it turns out that counters do vary too much between CPUs, there
might be ways that we can
On 12/17/07, Decibel! [EMAIL PROTECTED] wrote:
Also, has anyone looked into adding a class of system calls that
would actually tell us if the kernel issued physical IO? I find it
hard to believe that other RDBMSes wouldn't like to have that info...
Non-blocking style interfaces can help here.
On Dec 16, 2007 1:03 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
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
Gokulakannan Somasundaram [EMAIL PROTECTED] 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
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
Gokulakannan Somasundaram wrote:
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
On Fri, 2007-12-14 at 15:47 +, Gregory Stark wrote:
I've wanted for a long time to have EXPLAIN ANALYZE output per-node I/O usage.
This would be especially useful if we could distinguish hardware versus
logical I/O though. And I always thought that would be very hard.
My thought in the
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.
*** postgresql-8.3beta1/src/backend/storage/buffer/bufmgr.c
12 matches
Mail list logo
