Custom fields schema

[Joel Peshkin]

Kevin Benton wrote:

><snip>
>
>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.

-Joel