Nope, what I thought of wouldn't work in this case - I could not force the
optimizer to choose the quick plan without explicitly specifying the plan.

But there was one thing that puzzled me in your query. Shouldn't it be
...
LEFT OUTER JOIN contents ON (waybill.waybill =
contents.waybill and contents.item = 1)
WHERE ...

rather than having contents.item in the WHERE clause? No experience myself,
but I once read that the right part of a left outer join could only be
limited within the join itself, not in the WHERE clause. I doubt this would
be the source of your current problem, but it shouldn't take long to test
if you still have access to the slow database.

Set

At 08:23 02.10.2002 +0000, Rod Bracher wrote:

>SELECT routing.customsgroup, routing.waybill,
> waybill.surchargeflag1, waybill.surchargeflag2,
> waybill.surchargeflag3, waybill.surchargeflag4,
>waybill.waydate,
> waybill.service, waybill.origpers, waybill.origperadd1,
> waybill.origperadd2, waybill.origperadd3, waybill.origperadd4,
> waybill.destpers, waybill.destperadd1, waybill.destperadd2,
>waybill.destperadd3, waybill.destperadd4, waybill.destperphone,
> waybill.destpercontact, waybill.customsvalue,
>waybill.currency,
> waybill.pieces, waybill.actkg, waybill.chargemass,
>waybill.specinstruction,
> waybill.subtotal, place.town, contents.description
>
>FROM waybill
> INNER JOIN routing on (waybill.waybill = routing.waybill)
> LEFT OUTER JOIN place ON (waybill.destplace = place.place)
> LEFT OUTER JOIN contents ON (waybill.waybill =
>contents.waybill)
>
>WHERE routing.manifest =0
> and routing.mbranch =0
> and routing.mtype ='M'
> and contents.item = 1
>
>ORDER BY routing.customsgroup,routing.sortorder,routing.waybill