My group lead once rewrote a large complex query as a series of smaller queries and dealt with the resultsets in Perl. The operation as a whole went from 15 minutes to 10 seconds. Not only that, but the load on the database server went from 10 to 2, even though the number of queries went from 1 to 12.

That said, I would stress your benchmark a little. A difference of 3 hundredths of a second is, frankly, well within the statistical noise of a server. I'd run the two versions at least 10,000 times, just to make sure you're not hitting anomalous OS scheduler choices, root processes waking up, and the like.

Another impact might be your harddrive. Perl in enough RAM will generally beat a database on a single 7200rpm disk. However, move that to a mirrored 15,000 rpm pair of disks and you might have a different story.

A further impact might be the cardinality of your indices. The higher the cardinality, the fewer items there are per index value. This means that the index is more efficient, in that it will handle each item better. Some databases might not use low-cardinality indices as efficiently in a self-joined query as they would a higher-cardinality index.

Another item - your query should be rewritten.

select count(*)
  from theTable A
  inner join theTable B
 where (A.col_1 = x and B.col_1 = y and A.col_2 = B.col_2);

should become

SELECT COUNT(*)
  FROM theTable A JOIN theTable B ON (A.col_2 = B.col_2)
 WHERE A.col_1 = x
   AND B.col_1 = y
[download]

You have your join condition in your where clause. If you put it in your from clause, some optimizers might be able to take advantage of that.