Custom fields schema
bugreport at peshkin.net
Wed Jan 26 19:21:54 UTC 2005
Kevin Benton wrote:
>Right now, I can tell you that I am really beating up MySQL 3.23.x doing
>standard queries against the tables given with my statuscount.cgi. I was
>able to flood MySQL to the point where it took over a minute to get results
>back from a query that basically asked - show me a list of bugs that have
>been opened but never had a status change in it. Until I added some new
>indexes, that report was taking far too long to make it usable.
>Now, we're talking about having the ability to add custom fields. This is a
>good thing, but let's be sure we do it wisely. No matter which method we
>choose, it needs to be easy to use, understand, and perform without a
>serious hit to the DB. To do that - we must consider some kinds of custom
>fields that might be created and how that creation would happen. If it's
>something that can be handled without adding new code, then we should expect
>ours to handle optimization reasonably. If not, we should guide admins. on
>how to properly optimize after adding new fields.
For the record, Bugzilla will continue to be compatible with MySQL
3.23.x for a few more major releases but 3.23 is NOT the benchmark for
performance. Anyone using MySQL 3.23 will be presumed to be a small
site that doesn't care about optimum performance. Large
high-performance sites will be expected to be on MySQL 4.something.recent
When judging the resulting performance of a new feature, let's focus on
MySQL 4. Just don't break 3.23 altogether.
That said, the intention is to have BMO use custom fields as well, so it
cannot be a total dog.
More information about the developers