Ross,
Thanx to Stephan's help, I found out that after loading the tables w/
data, I had to run vacuum analyze to inform the optimizer of the amount
of data in the table (amongst other things, I imagine). After running
that on all the tables, the query performs fine.
-Brice
"Ross J. Reedstrom" wrote:
>
> Brice -
> What does EXPLAIN say for that query? With empty tables, I get two index scans,
> a merge join, and two sorts. I'm guessing wildly that you've got a non-optimal
> sort strategy happening somehow, given the four fold ORDER BY clause.
>
> Ross
>
> Here's the empty version:
>
> NOTICE: QUERY PLAN:
>
> Sort (cost=84.25..84.25 rows=100 width=64)
> -> Merge Join (cost=8.30..80.93 rows=100 width=64)
> -> Index Scan using pk_tblmedcond on tblmedcond (cost=0.00..60.00 rows=1000 width=36)
> -> Sort (cost=8.30..8.30 rows=10 width=28)
> -> Index Scan using pk_tblsidedruglink on tblsidedruglink (cost=0.00..8.14 rows=10 width=28)
>
> EXPLAIN
>
> On Thu, Feb 08, 2001 at 10:19:43AM -0600, Brice Ruth wrote:
> > FYI - I let the query run for 11.5 minutes before killing it off. It
> > had consumed 11 minutes, 18 seconds of CPU time (reported by ps). The
> > following messages are from the server log, I'm pasting in all messages
> > directly following the query:
> >
--
Brice Ruth
WebProjkt, Inc.
VP, Director of Internet Technology
http://www.webprojkt.com/