X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 3848952822 for ; Mon, 27 Jun 2005 19:41:46 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 23400-04 for ; Mon, 27 Jun 2005 22:41:40 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by svr1.postgresql.org (Postfix) with ESMTP id B490E52835 for ; Mon, 27 Jun 2005 19:41:38 -0300 (ADT) Received: (qmail 32633 invoked from network); 27 Jun 2005 22:41:42 -0000 Received: from dsl093-114-095.chi2.dsl.speakeasy.net (HELO mofo.meme.com) ([66.93.114.95]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jun 2005 22:41:42 -0000 Received: from mofo (localhost.localdomain [127.0.0.1]) by mofo.meme.com (Postfix) with ESMTP id 754536E421 for ; Mon, 27 Jun 2005 18:30:45 -0500 (CDT) Date: Mon, 27 Jun 2005 23:30:45 +0000 From: "Karl O. Pinc" Subject: Performance analysis of plpgsql code To: pgsql-performance@postgresql.org X-Mailer: Balsa 2.3.0 Message-Id: <1119915045l.4428l.5l@mofo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/508 X-Sequence-Number: 13145 Hi, I'm having a hard time finding the poorly performing statements in my plpgsql procedures, many of which are triggers. Am I missing something? I can get the query plans by starting up a new connection and doing: SET DEBUG_PRINT_PLAN TO TRUE; SET CLIENT_MIN_MESSAGES TO DEBUG1; And then running code that exercises my functions. Then I can find the queries that, in theory, could have problems. But problems remain after this. What I'd really like is a SET variable (or maybe a clause in CREATE FUNCTION) that causes any functions compiled to issue EXPLAIN ANALYZE output and the query text itself, to be RAISEd. Then I could watch the performance as it ran. Short of that I think I'm going to be reduced to writing a C function that returns the real system time so I can spatter my code with RAISE statements that indicate actual execution time. Is there a better approach? Does anybody have such a C function handy? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein