I think an option to have all queries returned in order is very important.
Without this, it will be difficult or even impossible to implement
network based variants of common algorithms, such as sorting.
Here is a purely software engineering example illustrating the value
of having the "query results in order" capability. Suppose you have
a partitioned database with 10000 shards, and your query is
parallelized into 10000 queries each returning up to 100 rows. The
query results are aggregated, and the aggregation algorithm takes into
account what shards results are coming from. Then, if results are
returned in order, then you may only need to allocate space for 100
result rows in the aggregating node. Otherwise, you need space for
1000000 result rows.
On Tue, May 19, 2009 at 6:11 AM, Konstantin Osipov <kostja@stripped> wrote:
> * Jim Winstead <jimw@stripped> [09/05/19 02:39]:
>> bug #26077 suggests that we make an api change so that an error will be
>> thrown if someone tries to send a query before the results of a previous
>> query have been read. this is using the not-really-documented
>> mysql_send_query()/mysql_read_query_result() api.
> mysql_send_query is not part of the C API, it's an internal
> If you use any of C API commands "Commands out of sync".
> Suggestion: do nothing about this bug.
>> i am inclined to not do this, since it may just confuse matters as we
>> evolve towards an asynchronous api, where you would absolutely expect to
>> be able to issue multiple queries and read the results in whatever order
>> they become available. (right now, you can issue multiple queries but
>> have to read the results in order.)
>> any thoughts?
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1