Chantal,
> Sort Key: disease.disease_name, disease_occurrences.sentence_id
> -> Nested Loop (cost=0.00..6922.38 rows=98 width=64) (actual
> time=61.49..275047.46 rows=18910 loops=1)
> -> Nested Loop (cost=0.00..6333.23 rows=98 width=28) (actual
> time=61.42..274313.87 rows=18910 loops=1)
> -> Nested Loop (cost=0.00..5894.04 rows=64 width=16) (actual
> time=32.00..120617.26 rows=46849 loops=1)
>
> I tried to tweak the conf settings, but I think I already reached
> quite a good value concerning shared buffers and sort mem. the
> database is vacuum full analyzed. indexes seem fine.
You *sure* that you've vacuum analyzed recently? The planner above is
choosing a bad plan because its row estimates are way off ... if the
subquery was actually returning 98 rows, the plan above would make
sense ... but with 18,000 rows being returned, a Nested Loop is
suicidal.
Perhaps you could post the full text of the query? If some of your
criteria are coming from volatile functions, then that could explain
why the planner is so far off ...
-Josh Berkus