Hello.
mysql_store_result stores the result set in a linked list (for memory
efficiency). With older versions mysql_data_seek always starts from
the beginning of the list and therefore has an O(n) complexity even
for sequential traversal.
IIRC, this was fixed with newer MySQL client libs, you either want to
upgrade or write some small wrapper.
For sequential retrieval, mysql_data_seek is redundant, because
fetch_row increases the data pointer by one.
Bye,
Benjamin.
PS: Btw, just yesteday I explained mysql_data_seek in another mail to
the list.
On Thu, Jun 21, 2001 at 05:40:50PM +1000, [EMAIL PROTECTED] wrote:
>
> I have been bench-marking an in-house higher-level library to access the
> MySQL database which uses the store_result and data_seek functions to
> provide random access to records in a selected dataset.
>
> This has brought to light that for 'large' result sets over 10,000 records,
> the data_seek is starting to take up an enormous portion of time, even when
> sequentially stepping through all the records once. Is this due to a
> limitation in the data_seek function? In one instance the comparison was:
>
> mysql_use_result + mysql_fetch_row (through total result set) = 3 seconds
>
> mysql_store_result + mysql_data_seek (through total result set) = 169 seconds
>
> This is without even taking into account the required fetch_row in the
> second case to actually access the data.
[...]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
