[development] MySql Performance Problem

nan wich nan_wich at bellsouth.net
Mon Jul 19 18:39:49 UTC 2010


Yes, I had considered that, but then I cannot use tablesort, which would be 
really nice to have.
 
Nancy




________________________________
From: Victor Kane <victorkane at gmail.com>
To: development at drupal.org
Sent: Mon, July 19, 2010 2:10:55 PM
Subject: Re: [development] MySql Performance Problem

You may ultimately wish to consider the option of grabbing at least some of the 
data in straightforward single table lookups into PHP hashes and then operating 
on those using PHP array operations, liberating yourself from so many MySQL 
joins and string ops. 


Victor Kane
http://awebfactory.com.ar


On Mon, Jul 19, 2010 at 3:05 PM, Mukesh Agarwal <mike4u4ever2001 at gmail.com> 
wrote:

I suggest not to index the votingapi tables, they are usually written very often 
and there adding an index will create an overhead.  

>
>
>The join clauses have a lot of string comparison. If you have a good index size, 
>then you should index the string fields first, else this query is always going 
>to be a bottleneck. 
>
>
>8000 nodes is actually not a lot, try removing the WHERE and ON clauses one by 
>one and you might find the solution. 
>
>Cheers,
>Mukesh 
>
>
>
>
>On Mon, Jul 19, 2010 at 11:25 PM, Domenic Santangelo <domenics at gmail.com> 
wrote:
>
>
>>
>>On Jul 19, 2010, at 10:18 AM, nan wich wrote:
>>
>>Can someone suggest ways to improve the performance?
>
>>First thing to do: indexes on the radioactivity, print_page_counter, 
>>print_mail_page_counter and (possibly) votingapi_cache tables. I say possibly on 
>>that one because I can't remember the behavior of that table and if indexing it 
>>might decrease performance elsewhere.
>>
>>hth,
>>D
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100719/5d653627/attachment.html 


More information about the development mailing list