User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 29 Jul 2005 12:02:30 -0700
Subject: Re: Performance problems testing with Spamassassin
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>,
 "Matthew Schumacher" <matt.s@aptalaska.net>
Cc: pgsql-performance@postgresql.org
Message-ID: <BF0FCB56.A410%llonergan@greenplum.com>
In-Reply-To: <20875.1122531559@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

On 7/27/05 11:19 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

> Matthew Schumacher <matt.s@aptalaska.net> writes:
>> After playing with various indexes and what not I simply am unable to
>> make this procedure perform any better.  Perhaps someone on the list can
>> spot the bottleneck and reveal why this procedure isn't performing that
>> well or ways to make it better.
> 
> There's not anything obviously wrong with that procedure --- all of the
> updates are on primary keys, so one would expect reasonably efficient
> query plans to get chosen.  Perhaps it'd be worth the trouble to build
> the server with profiling enabled and get a gprof trace to see where the
> time is going.

Yes - that would be excellent.  We've used oprofile recently at Mark Wong's
suggestion, which doesn't require rebuilding the source.

- Luke