[Devel] one more (possible) improovments of mysql module

Victor Gamov vit at lipetsk.ru
Wed Jun 20 21:51:04 CEST 2007


> Hello Victor,

Hi henning!

> sorry for the late reply, i was quite busy with work.

oh sorry for my persistence

> As i said before, fetch_result does quite a few functions calls that are not 
> needed for the normal and raw query case. So for this functions, that get 
> called a lot, the performance would decrease. Fetch_result is as twice as big 
> as store_result, is does this row counting, has some loops inside. This means 
> more code that needs to get executed, more possibilities for errors..
> 
> So i think we should stay with the current state. 

I check mysql/dbace.c and mysql/res.c once again and found following 
functions calls from db_mysql_store_result() and db_mysql_fetch_result():

db_mysql_store_result() == db_mysql_new_result + mysql_store_result() + 
db_mysql_convert_result()
db_mysql_convert_result == db_mysql_get_columns() + db_mysql_convert_rows()
db_mysql_convert_rows == mysql_num_rows() + internal-for-loop
internal-for-loop = mysql_fetch_row + db_mysql_convert_row


db_mysql_fetch_result() == db_mysql_new_result + mysql_store_result() + 
db_mysql_get_columns() + mysql_num_rows() + internal-for-loop
internal_for_loop = mysql_fetch_row() + db_mysql_convert_row()

So, db_mysql_store_result() uses more subfunctions calls while 
db_mysql_fetch_result() calls only really useful functions.

Now I change db_mysql_store_result() to db_mysql_fetch_result() in my 
1.2.1  and it works fine for my config (SELECT/UPDATE/INSERT queries are 
used).  I'll try to prepare patch later at this week.

> But if you want to work on the database interface, there are of course many 
> more improvements possible.. :-) 

:-)

"Nobody's Perfect" by Deep Purple :-)

> There are for example some functions present in the mysql module that are not 
> implemented for postgres:
> 
> - last_inserted_id (that should be easy)
> - replace

Yes, may be. But now I try to use OpenSER with MySQL only and I haven't 
Postgres

Thanks for your time!

-- 
CU,
Victor Gamov



More information about the Devel mailing list