Theoretical Performance Details of FAD vs. FAC (WAS Re:

[Max Kanat-Alexander]

	OK, I've discovered a few problems with the testing suite that was
used, on the integer-field-testing side. (Integer fields represent what
would be "single-select" fields.)

	(1) The test suite checks if a field is greater-than a certain value,
when most standard searches will be checking if it's *equal* to that
value. Checking equality happens to use MySQL indexes much more
efficiently than checking a greater-than.

	(2) The distcol_int table did not contain an ideal index. It should be
"UNIQUE (field_id, value, bug_id)".

	With those changes, I think the performance differences between FAC and
FAD would be pretty negligible for integer fields. (I don't have a
proper testing database to do in-depth testing on this).

	Other Performance Issues
	------------------------

	Another issue to think of is installations with lots of custom fields.

	For FAC, if we start putting all custom fields into one main table,
then that table will have a LOT of indexes on it. Bug creation could
become pretty slow.


	There are probably going to be problems with using ORDER BY on a custom
field in FAD, but we have those problems already with target_milestone
and the old enum fields. That's a more negligible problem, since ORDER
BY should be working on a generally small set of bugs.


	*ALL* the performance problems of Custom Fields, in either
implementation, are a symptom of the fact that MySQL will only use one
index for a query.

	I suspect that both implementations might perform better on PostgreSQL,
even though MySQL is supposed to perform better on reads like these. I'd
have to test that, though.

	-Max