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 k
"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
On Dec 18, 2007, at 3:32 AM, Gregory Stark 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...
Yeah, I think that's called "DTrace"
"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"
--
Greg
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 h
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 ac
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 v
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
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 fi
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 d
"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
> m
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
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 t
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 past was that would could do it on Solaris by having
Postgres
14 matches
Mail list logo
