that worked like a champ nice call as always! thanks
Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 7:07 PM To: Tim Jones Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] slow query using sub select "Tim Jones" <[EMAIL PROTECTED]> writes: > I am having a problem with a sub select query being kinda slow. The > query is as follows: > select batterycode, batterydescription, observationdate from Battery > t1 where patientidentifier=611802158 and observationdate = (select > max(observationdate) from Battery t2 where > t2.batterycode=t1.batterycode and patientidentifier=611802158) order by batterydescription. Yeah, this is essentially impossible for the planner to optimize, because it doesn't see any way to de-correlate the subselect, so it does it over again for every row. You might find it works better if you cast the thing as a SELECT DISTINCT ON problem (look at the "weather report" example in the SELECT reference page). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
