>>>>> "Tim" == Tim Bunce <Tim.Bunce@stripped> writes:
Tim> On Mon, Mar 13, 2000 at 01:12:26AM +0200, Michael Widenius wrote:
>>
Tim> Just to clarify this...
>>
Tim> a) you're proposing to add a _new_ option to SELECT to indicate that
Tim> the data should be buffered on the server before sending.
>>
>> Yes; The _new_option_ (SQL_USE_TEMPORARY_TABLE ?) will in effect
>> only set a flag that will force creation of a temporary table for the result.
Tim> Umm, I think a name closer to "buffer results" or "send unlocked" might
Tim> be more suggestive of 'why' rather 'how'. Just a thought.
Sounds resonable.
Tim> b) The subsequent sending of the data to the client would no longer
Tim> ever hold locks preventing other activity on other threads.
>>
>> This is already done for temporary tables.
Tim> I thought it was I just listed it for confirmation.
Tim> c) The _existing_ SQL_BIG_RESULT and SQL_SMALL_RESULT options would
Tim> be used to determine if the buffer should be on disk or in memory.
>>
>> Yes; Exactly as before.
>>
>> Note that in MySQL 3.23, the above option is not anymore that
>> necessary as MySQL will automaticly convert a HEAP internal temporary
>> table to a disk based one as soon as the temporary sets is bigger than
>> 'tmp_table_size'.
Tim> Great. That'll be very helpful. Thanks.
Tim> Thanks. I think this'll be a useful addition.
>>
Tim> Two more thoughts: It might be worth having a way to enable it as a
Tim> default for a whole session (eg for clients who know they're on a slow
Tim> network or machine etc). It might also be worth thinking about some way
Tim> to automatically detect slow clients and automatically enable the option
Tim> for them.
>>
>> Adding defaults is also trivial with a thread specific variable (just
>> as we do with SQL_BIG_RESULT). Automaticly detecting slow clients is
>> of course much harder...
Tim> I'm sure you can cheaply count, or estimate, the number of result bytes
Tim> sent to the client. And measuring the time from start to end of the send
Tim> should also be cheap and simple. On second resolution would suffice.
Tim> Those would give you a transmission rate.
This will however not solve the problems for clients that do a
reconnect between each query. I have to think about this (or just add
this as an extra option)
Regards,
Monty
