FYI (This was an internal reply I made, but I believe anyone on the
list would find it interesting).
Begin forwarded message:
Hi!
On Mar 16, 2009, at 1:29 AM, Jay Pipes wrote:
Frankly, libevent is being used entirely incorrectly in
pool_of_threads
plugin...
Yep!
Though even in its current state if you are doing just primary key
lookups it will outperform the threaded handler (spin up slap on the
key test). The problem is that you need to be able to catch a IO
event on a non-blocking port to make better use of it.
Though... the problem still exists that a port that continues to
"block" will hold up any other transactions that will conflict. In
the current state this is a bit worse then what it should be because
we are not releasing to another sessions well enough (aka... we need
to do this on IO event). Even fixing that though... this type of
scheduler will only really work for cases were you have short
transactions, or a large amount of read IO. In the end, libevent
just gives us a scheduler for one particular type of IO.
Long term? Some sort of scheduler that can grow or shrink... or
possibly something where we can really do priority in the queries
(aka... connect into the optimizer and use estimated cost).
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
