Is there only a benefit if I receive many rows or are they useful for simple selects with LIMIT 10 or similar?

What are the disadvantages?

regards

Cable TV providers are fighting it out with Satellite TV providers to see who can deliver the best service, most cutting edge technology, and ultimately win over the majority of customers by doing so. Unfortunately for the cable companies, when you loo…

I think you are right about congested networks – I’d expect on connection with big latency the buffering makes sence. Maybe I will test it somehow

Initial Time: 73.3s
Unbuffered: 59.3s

Using MySQLi: 39.46
MySQLi w/o store_result(): 26.44

So it would seem that your findings hold true for remote servers. Perhaps on a more congested network there would be a point when buffering would provide some benefit?

Thanks for taking the time to investigate this.

This problem of mysql_use_result mainly applies to MyISAM tables as table locks will be held for long time. Also it only applies to the cases then temporary table is not used to store full result set before sending it. For Innodb tables it is practically never problem due to onsistent reads for MyISAM tables it can be worked around by using SQL_BUFFER_RESULT option… It does buffering in temporary table. It is likely to kill all speed benefit on mysql_use_result however

mysql_use_result blocks other threads in next sense
(qoute from http://dev.mysql.com/doc/refman/5.0/en/mysql-use-result.html)

On the other hand, you shouldn’t use mysql_use_result() if you are doing a lot of processing for each row on the client side, or if the output is sent to a screen on which the user may type a ^S (stop scroll). This ties up the server and prevent other threads from updating any tables from which the data is being fetched.

Also other drawbacks of mysql_use_result:
When using mysql_use_result(), you must execute mysql_fetch_row() until a NULL value is returned, otherwise, the unfetched rows are returned as part of the result set for your next query. The C API gives the error Commands out of sync; you can’t run this command now if you forget to do this!

You may not use mysql_data_seek(), mysql_row_seek(), mysql_row_tell(), mysql_num_rows(), or mysql_affected_rows() with a result returned from mysql_use_result(), nor may you issue other queries until mysql_use_result() has finished.

Thank you! Great results!

I think even better results you can get with native C API and prepared statements.
It looks like in PHP binded variables have additional processing, but in C they are mapped to native
C variables and result is fetched without overhead.

About OO – no special reason. I just copy-pasted parts of code from PHP manual.
In common I also prefer procedural way, as historically OO works slow in PHP.

$dbh->{’mysql_use_result’}=0; #disable
$dbh->{’mysql_use_result’}=1; #enable

and since mysql 4.1 server based prepares can be used with:

$dbh->{’mysql_server_prepare’} = 1;

however the server based prepares will always use store_result instead of use_result for some reason according to some docs/forumposts.

One note, in the perl documentation it is said that use_result tends to block other processes. Is this also the case with php?

If Vadim has the possibility, could you please test the benchmark with say 10 och 100 concurrent runs of this testscript with use_result vs with store_result to see if some blocking migh occur which will make use_result slower than store_result for multiuser environments (like if you have more than 1 concurrent mysql query) ?

Thanks for pointing this out. I tried this on my database and I came up with the following results:

mysql_query:
Number of rows: 1000000. execution time: 24.53382897377 s

mysql_unbuffered_query: (same code, only changing mysql_query to mysql_unbuffered_query)
Number of rows: 1000000. execution time: 16.347587108612 s

I repeated this a few times and the above times seem to be persistent, ie almost the same for every run.

Now here is the kicker:

Using the new mysqli and prepared statement based on the code you provided:

Number of rows: 1000000. execution time: 1.9737339019775 s

BTW my table (InnoDB) has 10+ million records in there. The query I used:
SELECT * FROM `current` LIMIT 1000000;

I had to limit it to 1 million because it didn’t really like the whole 10 million (The waiting on the result drove me nuts)

Though I have to admit, the first time I ran this code it took 14 seconds. After a rerun it was around 1.9 to 2.0 s. Does mysql cache these prepared statements perhaps? Either way the performance benefit is worthwhile

Thank you for pointing this out. The code used for the last test is actually a few lines more and has somewhat more complicated due to the statement preparing etc. This shows the shortest and easiest path sure isn’t always the best

Is there any reason you used the OO style in your example instead of the procedural style? Myself, I used the procedural style.

Regards,

Peter