Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DEC506501A2 for ; Mon, 25 Aug 2008 11:23:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 72307-01-9 for ; Mon, 25 Aug 2008 11:23:40 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by postgresql.org (Postfix) with ESMTP id D73AD650176 for ; Mon, 25 Aug 2008 11:20:41 -0300 (ADT) Received: by gxk10 with SMTP id 10so2236744gxk.19 for ; Mon, 25 Aug 2008 07:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QMBeAUer786t7DIRkp+wU2NUh1A4I26MSckiFjt6rVQ=; b=eiNfAl6Pf0SsYrUHJYR49hA9w1mbG3g1G6Iz57B9sVJWx+JcEmce4hwS70MLqFDdBC wO2T93/jQeZa62v5keARkq3rm0iB6vKqNxgxLmB5TG7LO+fL8HNNB+6KF6J8PMuGEbBE da5VMWBXDAb2wg6Jl7JOWGCR0BYZ5Dzb42MeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jTcB3Fl9KnQowGujQqnL/+bnop3uOl00cUdsET68K1aMIm7phNI66wOghAC2kp3Tvh Yrp3ldt/bMySwkBRlzbv9E5cv+QCg9HczdL3/fO85e5RADiHcMaA3CYCti4yfgKcSVsX scqMGky5QsVqwfWj9/+Uf0OfHc14sc6R7+SEQ= Received: by 10.142.163.13 with SMTP id l13mr1554960wfe.34.1219674037091; Mon, 25 Aug 2008 07:20:37 -0700 (PDT) Received: by 10.142.86.13 with HTTP; Mon, 25 Aug 2008 07:20:37 -0700 (PDT) Message-ID: <36e682920808250720p2931727cif70447be301bd71c@mail.gmail.com> Date: Mon, 25 Aug 2008 10:20:37 -0400 From: "Jonah H. Harris" To: "Peter Schuller" Subject: Re: Identifying the nature of blocking I/O Cc: pgsql-performance@postgresql.org In-Reply-To: <20080822115243.GA10981@hyperion.scode.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080822115243.GA10981@hyperion.scode.org> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/324 X-Sequence-Number: 31205 On Fri, Aug 22, 2008 at 7:52 AM, Peter Schuller wrote: > Is there currently a way of dumping such information? I.e., asking PG > "what are backends waiting on right now?". Unfortunately, not within Postgres itself. The question, "what is the database waiting on?" is a good one, and one Oracle understood in the early 90's. It is for that reason that EnterpriseDB added RITA, the Runtime Instrumentation and Tracing Architecture, to their Advanced Server product. RITA gives DBAs some of the same information as the Oracle Wait Interface does regarding what the database is waiting for, such as locks, I/O, and which relation/block. While it's not as efficient as DTrace due to Linux's lack of a good high-resolution user-mode timer, no one has found it to have a noticible overhead on the throughput of a system in benchmarks or real-world applications. If you're on a DTrace platform, I would suggest using it. Otherwise, you can try and use strace/ltrace on Linux, but that's probably not going to get you the answers you need quickly or easily enough. Until enough users ask for this type of feature, the community isn't going to see it as valuable enough to add to the core engine. IIRC, systemtap is pretty much dead :( -- Jonah H. Harris, Senior DBA myYearbook.com