> I still think that this is a bug in the DBD Oracle driver. > DBI_TRACE=3 produced exact same results for the two queries. > So, the problem is how the driver passes these values to Oracle.
Since the type was shown to be the same in both cases by the trace, doesn't this seems to move the probable location of the issue towards Oracle, rather than DBD::Oracle? You should be able to get hold of the actual execution plans used by looking into v$sql_plan - this would at least give some information on why one takes long than the other, because so far there's no definite explanation for the differences in elapsed time. You'll need the address/hash_value from v$sql, or v$session.sql_address/sql_hash_value. Also see: http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:103534539 05351 ... for a way to use DBMS_XPLAN to get nicely formatted execution plans from cached SQL (in 10g DBMS_XPLAN has extra functionality to this directly). Or use Oracle's tracing functionality. Another way of looking at it - can you reduce this to a small self-contained test case that can be tested on other databases? -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
