<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean McAfee wrote:
<blockquote cite="mid20050325182533.E1346BC77@mail.schwag.org"
type="cite">
<pre wrap="">Myk Melez <a class="moz-txt-link-rfc2396E" href="mailto:myk@mozilla.org"><myk@mozilla.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">David Miller wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Has there been any good performance analysis on which one would
actually work faster?
</pre>
</blockquote>
</blockquote>
<blockquote type="cite">
<pre wrap="">Yes. I did a bunch of tests which showed FAC to be significantly
faster. See the "Custom fields schema" thread from January and February
for my test results.
</pre>
</blockquote>
<pre wrap=""><!---->
And I did a bunch of tests before that which showed just the opposite.
Until the discrepancy can be explained, neither set of tests should be
regarded as definitive, IMHO.
</pre>
</blockquote>
It's not that simple. You provided a script for generating sample
data, some test queries you ran manually, and some results you compiled
by hand. I provided a script for generating sample data; a script for
running a more comprehensive set of tests (including yours) and
generating results automatically; and test results for two different
machines.<br>
<br>
I also ran the tests on a third machine and confirmed that its results
were the same as for the first two. My tests were more rigorous, and
they were reproduced on several machines, so they are more likely to be
correct than yours.<br>
<br>
Nevertheless, note that I argue for FAD not primarily because of the
performance implications but because it makes more sense from a design
standpoint for the kinds of data we're storing. I won't rehash the
arguments here, as they're well explored in the thread earlier this
year.<br>
<br>
<blockquote cite="mid20050325182533.E1346BC77@mail.schwag.org"
type="cite">
<pre wrap="">One difficulty for me has been that Myk has yet to fully define his
proposal. Whether fields live in columns all in the same table, all in
different tables, or divided between various tables in some fashion, and how
the administrator would manage things in the last case, he has never stated,
unless I've missed something.</pre>
</blockquote>
It's not ambiguity. In my proposal all three field locations are
available, and each can be selected on a per-field basis depending on
which location is optimal for a given field. But we would choose a
good default, automate the selection and updating of a location via
administrative UI, and implement support for the locations iteratively,
starting with the good default that most fields will use.<br>
<br>
-myk<br>
<br>
</body>
</html>