From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Matthew Schumacher" <matt(dot)s(at)aptalaska(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance problems testing with Spamassassin |
Date: | 2005-07-29 19:02:30 |
Message-ID: | BF0FCB56.A410%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom,
On 7/27/05 11:19 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Matthew Schumacher <matt(dot)s(at)aptalaska(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Schumacher | 2005-07-29 19:16:52 | Re: Performance problems testing with Spamassassin |
Previous Message | Jeffrey W. Baker | 2005-07-29 18:55:42 | Re: Performance problems on 4/8way Opteron (dualcore) HP |