From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fran Fabrizio <ffabrizio(at)mmrd(dot)com> |
Cc: | Shaun Thomas <sthomas(at)townnews(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: horrendous query challenge :-) |
Date: | 2002-05-30 18:54:24 |
Message-ID: | 2429.1022784864@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Fran Fabrizio <ffabrizio(at)mmrd(dot)com> writes:
> Performance is about 2-3x's better, but still taking around 40s. Now
> that we've eliminated the view and it's function calls, and the IN, this
> seems pretty straightforward. My next stop was to check on the one
> remaining function call, the findsite() in the where clause. But, I
> have spent about a week's time in the past working on that one and it's
> fairly well optimized, down to about .003 seconds per call.
Nonetheless, it's being evaluated 202*153 or almost 31000 times per
query. Your .003 is an overestimate since it includes all the overhead
of query parsing/planning, but it still appears that those function
calls are the bulk of the runtime.
What is findsite doing exactly? If it's a table lookup, maybe you could
inline it into this query and get some optimization.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Wolfe | 2002-05-30 19:10:20 | Re: Scaling with memory & disk planning |
Previous Message | Antai Ning | 2002-05-30 18:11:09 | The application dies when insertion fails. |