Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C00A79FA621 for ; Wed, 27 Sep 2006 18:33:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 11769-07 for ; Wed, 27 Sep 2006 18:33:39 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from larry.aptalaska.net (larry.aptalaska.net [64.186.96.3]) by postgresql.org (Postfix) with ESMTP id D869B9FA1DE for ; Wed, 27 Sep 2006 18:33:38 -0300 (ADT) Received: from [192.168.98.9] (rdbck-static-287.palmer.mtaonline.net [64.4.232.33]) (authenticated bits=0) by larry.aptalaska.net (8.13.8/8.13.6) with ESMTP id k8RLXAu1006541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 13:33:11 -0800 Message-ID: <451AEE15.6090103@aptalaska.net> Date: Wed, 27 Sep 2006 13:33:09 -0800 From: Matthew Schumacher User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Jim C. Nasby" CC: pgsql-performance@postgresql.org Subject: Re: Problems with inconsistant query performance. References: <451AC4E2.90106@aptalaska.net> <20060927203155.GT19827@nasby.net> In-Reply-To: <20060927203155.GT19827@nasby.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Bayes: Learn: ham X-Scanned-By: MIMEDefang 2.56 on 64.186.96.3 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.15 tagged_above=0 required=5 tests=AWL, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/373 X-Sequence-Number: 21059 Jim, Thanks for the help. I went and looked at that example and I don't see how it's different than the "INSERT into radutmp_tab" I'm already doing. Both raise an exception, the only difference is that I'm not doing anything with it. Perhaps you are talking about the "IF (NOT FOUND)" I put after the "UPDATE radutmp_tab". Should this be an EXCEPTION instead? Also I don't know how this could cause a race condition. As far as I understand each proc is run in it's own transaction, and the code in the proc is run serially. Can you explain more why this could case a race? Thanks, schu Jim C. Nasby wrote: > Periodically taking longer is probably a case of some other process in > the database holding a lock you need, or otherwise bogging the system > down, especially if you're always running acctmessage from the same > connection (because the query plans shouldn't be changing then). I'd > suggest looking at what else is happening at the same time. > > Also, it's more efficient to operate on chunks of data rather than one > row at a time whenever possible. If you have to log each row > individually, consider simply logging them into a table, and then > periodically pulling data out of that table to do additional processing > on it. > > BTW, your detection of duplicates/row existance has a race condition. > Take a look at example 36-1 at > http://www.postgresql.org/docs/8.1/interactive/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING > for a better way to handle it. >> ========================================================================== >> CREATE acctmessage( )RETURNS void AS $$ >> BEGIN >> INSERT into tmpaccounting_tab ( ... ) values ( ... ); >> >> IF _acctType = 'start' THEN >> BEGIN >> INSERT into radutmp_tab ( ... ) valuse ( ... ); >> EXCEPTION WHEN UNIQUE_VIOLATION THEN >> NULL; >> END; >> ELSIF _acctType = 'stop' THEN >> UPDATE radutmp_tab SET ... WHERE sessionId = _sessionId AND userName = >> _userName; >> IF (NOT FOUND) THEN >> INSERT into radutmp_tab ( ... ) values ( ... ); >> END IF; >> >> END IF; >> END; >> $$ >> LANGUAGE plpgsql; >> ==========================================================================