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

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 ?


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:
libdbi-users mailing list

Reply via email to