On Tue, Feb 17, 2009 at 6:20 PM, Brian Aker <[email protected]> wrote: > Hi! > > On Feb 17, 2009, at 6:23 AM, MARK CALLAGHAN wrote: > >> the THD object caches the pointer to the HASH entry for the user and >> the global counter value at which the pointer is valid. When FLUSH >> > > Yep. You can think for the most part that when we say Session... you can > think THD (though there are some obvious differences in ours since they are > connected to the executing thread). When the session is created we just tell > it the key it is to use in scoreboard. > > As far as per table stats go... I've been wondering about just leaving this > to the engines and instead requesting data from them. I've not really put > enough thoughts into this yet (this is for work past April). >
For the cost of one extra function call on the path to read/write/... a row you can put code for this in handler.cc and have handler.cc invoke the function provided by the storage engine. The benefit is that this makes it easier for drizzle to integrate storage engines with fewer changes. > >> to check that the pointer is still valid and update fields. Most of >> the field updates could be done lock-free except for one. We have a >> Concurrent_connections field that must be correct. Of course atomic >> ops could provide that. > > > I want to avoid all locks for update and for session creation (aka... people > write apps that connect/disconnect... I want minimal penalty for doing > that). For update that means a read will be dirty, but I believe that should > be fine. For update this is not an issue since a session is unique within > the system. If you intend to aggregate these per user/table, at some point the global counters per user/table must be updated. If these updates are to be exact, then the choices are to use a mutex or to use atomic ops such as fetch&add when supported. > > I've not entirely thought of a good method yet for getting the slot in the > scoreboard for the connection, other then using the atomic value of > "connection number" and relating this back to the scoreboard. That still > requires an ATOMIC,... and those are not entirely free from cost. > > BTW there is still in Drizzle a silly lock for SHOW PROCESSLIST to show the > current "SQL" being executed. There is some refactoring I need to do to get > rid of that. > > 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. > > > > -- Mark Callaghan [email protected] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
