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 B519E52991 for ; Wed, 27 Jul 2005 23:11:54 -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 94603-03 for ; Thu, 28 Jul 2005 02:11:44 +0000 (GMT) Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by svr1.postgresql.org (Postfix) with ESMTP id 3119952998 for ; Wed, 27 Jul 2005 23:11:43 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [63.195.55.98] (account josh@agliodbs.com HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 7663255; Wed, 27 Jul 2005 19:14:01 -0700 From: Josh Berkus Organization: Aglio Database Solutions To: Matthew Schumacher Subject: Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Date: Wed, 27 Jul 2005 19:12:39 -0700 User-Agent: KMail/1.8 Cc: pgsql-performance@postgresql.org References: <42E80C28.2040608@aptalaska.net> <200507271712.15299.josh@agliodbs.com> <42E83C09.2040508@aptalaska.net> In-Reply-To: <42E83C09.2040508@aptalaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507271912.39780.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.012 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200507/427 X-Sequence-Number: 13668 Matt, > UPDATE bayes_vars SET > $token_count_update > newest_token_age = GREATEST(newest_token_age, ?), > oldest_token_age = LEAST(oldest_token_age, ?) > WHERE id = ? > > > I think the reason why the procedure was written for postgres was > because of the greatest and least statements performing poorly. Well, it might be because we don't have a built-in GREATEST or LEAST prior to 8.1. However, it's pretty darned easy to construct one. > Honestly, I'm not real up on writing procs, I was hoping the problem > would be obvious to someone. Well, there's the general performance tuning stuff of course (postgresql.conf) which if you've not done any of it will pretty dramatically affect your througput rates. And vacuum, analyze, indexes, etc. You should also look at ways to make the SP simpler. For example, you have a cycle that looks like: SELECT IF NOT FOUND INSERT ELSE UPDATE Which could be made shorter as: UPDATE IF NOT FOUND INSERT ... saving you one index scan. Also, I don't quite follow it, but the procedure seems to be doing at least two steps that the MySQL version isn't doing at all. If the PG version is doing more things, of course it's going to take longer. Finally, when you have a proc you're happy with, I suggest having an expert re-write it in C, which should double the procedure performance. -- Josh Berkus Aglio Database Solutions San Francisco