Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

On the Internet Super Hero blog, there's a post that looks at how PDO is implemented in PHP and wonders if the PDO::FETCH_UNIQUE constant is broken (as something to fix before even considering the move to PDO2).

I spent quite a lot of time comparing the different behaviours of the various drivers in the hope I could find out how PDO drivers are supposed to work. The PDO documentation and the specification do not cover each and every detail. PDO really needs some love...

He picks out the FETCH_UNIQUE constant as one that needs a little work and tries to track down exactly what it's doing. One issue he found was that it requires combination with other flags to make the unique part of it work correctly (like FETCH_OBJ or FETCH_COLUMN). He works through several examples, both ones that apply the unique call and others that don't, comparing the results.