From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, "Hartman, Matthew" <Matthew(dot)Hartman(at)krcc(dot)on(dot)ca>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Explaining functions. |
Date: | 2009-06-23 14:19:18 |
Message-ID: | 937d27e10906230719k7df458c1ja42d9eb4152a490c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jun 23, 2009 at 3:04 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Tue, Jun 23, 2009 at 8:03 AM, Hartman,
>> Matthew<Matthew(dot)Hartman(at)krcc(dot)on(dot)ca> wrote:
>>> Is there a recommended approach when trying to use EXPLAIN on a
>>> function? Specifically, a function that is more than the typical SELECT
>>> statement or tiny loop. The one in question that I'm hoping to optimize
>>> is around 250 lines.
>
>> What I normally do for benchmarking of complex functions is to
>> sprinkle the source with "raise notice '%', timeofday();" to figure
>> out where the bottlenecks are. Following that, I micro-optimize
>> problem queries or expressions outside of the function body in psql.
>
> There was some discussion once of using the same infrastructure the
> plpgsql debugger uses to build a plpgsql profiler. That would help
> automate the first part of this, at least. Anybody know the status
> of that project?
There is a profiler in the debugger source tree. Iirc, it dumps it's
data out to an XML in a not-so-friendly manner. I haven't ever tested
it, so it may have been broken since Korry handed it over.
http://pgfoundry.org/scm/?group_id=1000175
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-06-23 14:24:28 | Re: Replication |
Previous Message | Greg Stark | 2009-06-23 14:18:14 | Re: Cache lookup failed for type 70385664 |