Hello everyone, I'm following a quite old topic about libdbi speed issues. I was able to track the cause of these issues : The major problem is how libdbi goes from one row to another.
RRDTool (the tool that used libdbi and that I was inspecting) is using dbi_result_next_row() function (as stated in libdbi documentation btw). This function moves from one row to another with function dbi_result_seek_row(), incrementing currentRow index each time. This gives a call to dbd_mysql.c::dbd_goto_row() that uses mysql_data_seek() each time... That's why for a query result of 34k rows (yes it happens. No it is not a problem in the query itself), we have tens of thousands of call to this function (which is very low), and this is definitely not needed, because as we use fetch_row(), we automatically move from one row to another. Seeking is just a useless task (as internal driver does not know where we are, and needs to start from row 0 and seek to the given row - where we already were). I'm absolutely not a libdbi user, and I don't know what could be done outside libdbi to not use dbi_result_next_row() and use directly RESULT->onn->driver->functions->fetch_row() directly. Is it possible ? And/or patching dbi_result.c : just check RESULT->currowidx near line 102 before calling doing goto_row() function and call it only if we are not on the good row. Am I right ? Olivier ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
