List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:December 7 2000 1:22pm
Subject:Re: MySQL protocol efficiency
View as plain text  
Hi!

>>>>> "bruce" == bruce  <bruce@stripped> writes:

bruce> On Thu, Dec 07, 2000 at 10:51:13AM +0200, Michael Widenius wrote:
>> The extra bytes is not a major overhead as most results are small. The
>> formatting of numbers is however a major overhead that we want to get
>> rid off!

bruce> Good, then it has been noticed.

Yes (a long time)

>> To maintain the compatibility to old clients, we plan to solve this
>> approximately the following way:
>> 
>> - Extending the MySQL interface so that the user can bind variables to
>> the parameters and results.
>> - When a uses uses the new bind function, we will tell the server this
>> by using COM_BINARY_QUERY instead of COM_QUERY.
>> - The server will now send the data binary and the client will store
>> it in binary format.
>> - When the client executes mysql_fetch_data(), we will then copy
>> the data to the bound variables.
>> - We will also support binding of strings to pointers, to avoid
>> having to copy the data.

bruce> I didn't notice it on the "things that need to be implemented" list. I
bruce> take this to mean that it's a fairly low priority :(

It has actually a quite high priority;  I have had this in mind a long
time but I have forgot to add this to the TODO ;  (I just added it)

>> Now we only need someone to implement the above :)

bruce> Perhaps if I get bored over the hollidays.  It would be nice to 
bruce> contribute.

That would be REALLY nice!

bruce> Now for another question.  It is possibly related the points above. 
bruce> What is the overhead of parsing a SQL query from a string into it's 
bruce> intermediate format (the format that the server uses to process
bruce> the query)?  

MySQL has a very fast parser, but it's still and overhead.  For most
queries it's neglectable just because the query takes so long to
execute, but for simple things it's can be up 1-10 % of the total
time.  Another win is that if the server can get the strings
'unescaped', we can save memory as we don't need to save a copy of the
unescaped string argument but can use a pointer to the original string!

bruce> If it is significant and the query is used multiple times with only a
bruce> few constants changing, then pre-parsing it and using the intermediate 
bruce> form will save you time.  This obviously isn't a new idea, as it's
bruce> the basis of the JDBC PreparedStatement, but I think it could prove
bruce> very useful.

Yes, it would be very useful to have this;  It would also make the
MyODBC driver much faster as it doesn't have to pre-parse the query to
find the parameters for the query.

Regards,
Monty
Thread
MySQL protocol efficiencybruce7 Dec
  • MySQL protocol efficiencyMichael Widenius7 Dec
    • Re: MySQL protocol efficiencybruce7 Dec
      • Re: MySQL protocol efficiencyMichael Widenius7 Dec
        • Re: MySQL protocol efficiencySasha Pachev7 Dec