List:Internals« Previous MessageNext Message »
From:Brian Aker Date:July 5 2008 2:02am
Subject:Re: mutex contention for the query cache
View as plain text  
Hi!

On Jul 4, 2008, at 4:55 PM, MARK CALLAGHAN wrote:

> There is a Stonebraker research project on an OLTP engine called
> H-store that partitions data so that one core gets each partition.
> Locking is not an issue at that point. MySQL Cluster could approximate
> that deployment model.

This is the one place where in the discussion of thread vs process  
that process based DB's (and what I am really talking about is  
Postgres) could bind processes to particular processors/sets of cores  
and arbitrate out access to those workers. By using processes you get  
a natural affinity for any sort of lock call to stay with the confines  
of a particular processor.

You could get this by using "node collections" of MySQL servers. This  
was something that was talked about after we looked at a new design  
for prepared statements so that proxies/anything could do a bit easier  
work on incoming queries.

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.



Thread
mutex contention for the query cacheMARK CALLAGHAN3 Jul
  • Re: mutex contention for the query cacheMARK CALLAGHAN3 Jul
    • Re: mutex contention for the query cacheMARK CALLAGHAN3 Jul
      • RE: mutex contention for the query cacheRick James3 Jul
        • Re: mutex contention for the query cacheMARK CALLAGHAN3 Jul
          • RE: mutex contention for the query cacheRick James3 Jul
            • Re: mutex contention for the query cacheMARK CALLAGHAN3 Jul
              • Re: mutex contention for the query cacheBrian Aker3 Jul
              • Re: mutex contention for the query cacheSergei Golubchik3 Jul
          • Re: mutex contention for the query cacheKonstantin Osipov3 Jul
            • Re: mutex contention for the query cacheBrian Aker3 Jul
              • Re: mutex contention for the query cacheSergey Petrunia3 Jul
                • Re: mutex contention for the query cacheBrian Aker3 Jul
                  • Re: mutex contention for the query cacheSergei Golubchik3 Jul
                    • Re: mutex contention for the query cacheBrian Aker4 Jul
                      • Re: mutex contention for the query cacheJonas Oreland4 Jul
                        • Re: mutex contention for the query cacheSergei Golubchik4 Jul
                          • Re: mutex contention for the query cacheJonas Oreland4 Jul
                            • Re: mutex contention for the query cacheJonas Oreland4 Jul
                              • Re: mutex contention for the query cacheKonstantin Osipov4 Jul
                      • Re: mutex contention for the query cacheMark Leith4 Jul
                      • Re: mutex contention for the query cacheMARK CALLAGHAN4 Jul
                        • Re: mutex contention for the query cacheBrian Aker4 Jul
                          • Re: mutex contention for the query cacheMARK CALLAGHAN5 Jul
                            • Re: mutex contention for the query cacheBrian Aker5 Jul
                            • Re: mutex contention for the query cacheJonas Oreland2 Aug
                              • Re: mutex contention for the query cacheFrazer Clement5 Aug
  • Re: mutex contention for the query cacheKonstantin Osipov3 Jul
  • Re: mutex contention for the query cacheJocelyn Fournier3 Jul
    • RE: mutex contention for the query cacheRick James3 Jul
      • Re: mutex contention for the query cacheJocelyn Fournier3 Jul
        • RE: mutex contention for the query cacheRick James3 Jul
  • Re: mutex contention for the query cacheAntony T Curtis3 Jul