From: Davi Arnaut
Date: May 12 2009 11:30pm
Subject: Re: MySQL Reengineering Project
List-Archive: http://lists.mysql.com/internals/36662
Message-Id: <4A0A0685.2050704@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT

On 5/12/09 5:58 PM, Jay Pipes wrote:
> Sergei Golubchik wrote:
>
>>>>> Without doing this, and using encapsulation so that a THD can have
>>>>> multiple Statements, it will be very difficult to work on any future
>>>>> parallelization efforts.
>>>> You mean, a Statement can have multiple THDs, I suppose :)
>>> No he means what he is saying. I don't know why you would want a
>>> statement shared across multiple THD, but having a THD be able to
>>> handle multiple statements means that you can do asynchronous queries
>>> within a single connection.
>>
>> Ah, okay. I see.
>>
>> I thought that "parallelization", that Jay mentioned, means executing
>> parts of a single statement in different threads - which, indeed, may
>> need two THDs sharing the same Statement.
>
> Yes, what Brian says...once the THD is distinguised from a pthread,
> intra-statement parallelization is possible. We've only just begun this
> step in Drizzle (a Session is now no longer intricately linked to a
> pthread in Drizzle) but there's clearly a ton more to do. :) I know Alex
> Esterkin thinks there is no reason to do such as thing, but perhaps he
> just needs an example :)
>
> Imagine a Session which sends a few long-running SELECTs in the same
> client connection. Currently, because the THD is linked to a single
> pthread in MySQL, these SELECTs will not only block each other, but will
> be executed in order. What if there was no reason to do so? The three
> Statements, if a Session contained a vector of Statement objects, could
> parse and optimize all three statements and decide to send two of them
> off to other scheduler threads for execution, essentially parallelizing
> the operation (particularly on a distributed node architecture...)
>

Jay,

What are the advantages of this schema over making a session as 
lightweight as possible and the user using multiple sessions? The latter 
seems less complicated and could yield better parallelism if the right 
cards are played within the server.

Davi