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 6F09952C26 for ; Mon, 1 Aug 2005 17:04:27 -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 17736-01 for ; Mon, 1 Aug 2005 20:04:22 +0000 (GMT) Received: from larry.aptalaska.net (larry.aptalaska.net [64.186.96.3]) by svr1.postgresql.org (Postfix) with ESMTP id ECD1252C3C for ; Mon, 1 Aug 2005 17:04:20 -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.4/8.13.4) with ESMTP id j71KIWF6025299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 12:18:32 -0800 Message-ID: <42EE8043.1050207@aptalaska.net> Date: Mon, 01 Aug 2005 12:04:19 -0800 From: Matthew Schumacher User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: pgsql-performance@postgresql.org Subject: Re: Performance problems testing with Spamassassin 3.1.0 References: <42E80C28.2040608@aptalaska.net> <1122532023.25574.1.camel@localhost.localdomain> <42E9749F.6000709@aptalaska.net> <1122616211.5691.340.camel@lamb.mcmillan.net.nz> <42EA6966.8090402@aptalaska.net> <1122668371.5691.352.camel@lamb.mcmillan.net.nz> <19405.1122670917@sss.pgh.pa.us> <42EAA410.9010700@aptalaska.net> <27897.1122748133@sss.pgh.pa.us> In-Reply-To: <27897.1122748133@sss.pgh.pa.us> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Bayes: Learn: unavailable X-Scanned-By: MIMEDefang 2.52 on 64.186.96.3 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.007 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200508/7 X-Sequence-Number: 13754 Tom Lane wrote: > > Revised insertion procedure: > > > CREATE or replace FUNCTION put_tokens (_id INTEGER, > _tokens BYTEA[], > _spam_count INTEGER, > _ham_count INTEGER, > _atime INTEGER) > RETURNS VOID AS > $$ > declare _token bytea; > new_tokens integer := 0; > BEGIN > for i in array_lower(_tokens,1) .. array_upper(_tokens,1) > LOOP > _token := _tokens[i]; > UPDATE bayes_token > SET spam_count = spam_count + _spam_count, > ham_count = ham_count + _ham_count, > atime = _atime > WHERE id = _id > AND token = _token; > > IF not found THEN > INSERT INTO bayes_token VALUES (_id, _token, _spam_count, > _ham_count, _atime); > new_tokens := new_tokens + 1; > END IF; > END LOOP; > if new_tokens > 0 THEN > UPDATE bayes_vars SET token_count = token_count + new_tokens > WHERE id = _id; > IF NOT FOUND THEN > RAISE EXCEPTION 'unable to update token_count in bayes_vars'; > END IF; > END IF; > RETURN; > END; > $$ > LANGUAGE plpgsql; > Tom, thanks for all your help on this, I think we are fairly close to having this done in a proc. The biggest problem we are running into now is that the data gets inserted as an int. Even though your proc defines _token as byeta, I get numbers in the table. For example: select put_tokens2(1, '{"\\246\\323\\061\\332\\277"}', 1, 1, 10000); produces this: id | token | spam_count | ham_count | atime ----+-----------------+------------+-----------+------- 1 | 246323061332277 | 1 | 1 | 10000 I'm not sure why this is happening, perhaps the problem is obvious to you? Thanks, schu