MySQL user's Conference
Bradley Baetz
bbaetz at acm.org
Fri Apr 18 07:10:46 UTC 2003
On Fri, Apr 18, 2003 at 02:50:31AM -0400, Daniel Berlin wrote:
> Well, if you are cpu bound, and are using 4.x, among other things, you
> should turn on the query cache (It's disabled by default).
bmo is 3.23.x.
> I dunno if anyone ever tuned the mysql on b.m.o. If not, you probably
> want to look at the my-(huge, large).cnf files that exist somewhere
> (it's in /usr/share/mysql on my machine).
> They are generally the settings you should be using as a starting point
> to tune from (huge is for 1G-2G mainly mysql running machines, large is
> for 512M mainly mysql running machines)
I have this vague recollection that its a 4G machine, but I'm not
too sure.
> For GCC, our attachments are mainly huge preprocessed source files, so
> it helps quite a bit.
> We get about a 70% reduction in attachment size.
Yeah, it would help with the size, but since its on a separate table
which we really don't look at that often I don't think it would save
anything apart from diskspace.
> It might, there were some problems in the range optimizer of 3.x with
> InnoDB, i believe.
>
It could be. I think the plans were teh same, though, but I can't really
remember.
> I'll also note that if I create a bug_id, who index, like so:
>
> create index bug_id_who on longdescs(bug_id, who);
>
> then both database types use the new index for the query, and the query
> takes 0.1 on either MyISAM or InnoDB.
Well, thats a mysql limitation again. :)
> If this query is common, we should probably add this index.
Its not; it was just an example in a bug somewhere which was easy to set
up a simple test for. Thats the issue; buglist.cgi is basically
completely ad-hoc, so its hard to tune correctly.
Bradley
More information about the developers
mailing list