<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Ashley,<br>
<br>
Thanks very much for starting this discussion. This is a really
good starting point.<br>
<br>
What I would like is that if everybody who has an interest in the
structure of this database can provide their feedback on the
structure that Ashley has proposed and see if it will work for
their anticipated needs.<br>
<br>
As I see it there are at least three interests we need to support:
Energy Measurement; the MAGEEC framework; ML.<br>
<br>
Perhaps all sides could outline the suitability of the proposed
structure for their needs?<br>
<br>
P.S. for Magicians: If you received this message, but not Ashley's
original one, it is because you are not yet signed up for the
external <a class="moz-txt-link-abbreviated" href="mailto:mageec@mageec.org">mageec@mageec.org</a> mailing list. Please do so!<br>
<br>
<br>
On 28/08/13 17:21, Ashley Whetter wrote:<br>
</div>
<blockquote
cite="mid:CAFECyJLacM_jczv01isvXdzSuAy1-O_i9quekxg-ccopaS7=ZQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hey everyone,
<div><br>
</div>
<div>At the last meeting we looked at the ER diagram (<a
moz-do-not-send="true"
href="http://mageec.org/wiki/Database">http://mageec.org/wiki/Database</a>) for
the database that would store the results that would be
recorded by the test framework and used by the plugin.</div>
<div><br>
</div>
<div>I've taken some of the comments made at the meeting and
made a more detailed ER diagram to discuss. (<a
moz-do-not-send="true"
href="http://mageec.org/w/images/1/19/Results_ERD_Proposal.png">http://mageec.org/w/images/1/19/Results_ERD_Proposal.png</a>)</div>
<div><br>
</div>
<div>A test (and test id) refers to a single combination of a
platform, compiler, benchmark, and flag set.</div>
<div>A run (and run id) refers to a single run of a test. A test
can have multiple runs.</div>
<div><br>
</div>
<div>Currently the flag table is only really storing a flag name
(eg "-fgcse", "-fno-gcse", etc). I've kept this as a separate
table, though, because eventually we'll want to start storing
values for flags that aren't just on or off. We could add this
value field now, keep the table as is for now, or get rid of
flag_id all together and just use the flag name in flags_tests
instead.</div>
<div><br>
</div>
<div>I've put summary data in the runs table. We could split
this out into a different results table, but it's a one-to-one
relationship it would add an unnecessary overhead of joining
the runs and results table when we want to search it. This
isn't such a problem if we search for results by run_id
though.</div>
<div><br>
</div>
<div>The raw_results table is the bottleneck. We record 200,000+
individual results for a single run, so this table will get
really quickly.</div>
<div><br>
</div>
<div><br>
</div>
<div>Ashley</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mageec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mageec@mageec.org">mageec@mageec.org</a>
<a class="moz-txt-link-freetext" href="http://mageec.org/cgi-bin/mailman/listinfo/mageec">http://mageec.org/cgi-bin/mailman/listinfo/mageec</a>
</pre>
</blockquote>
<br>
</body>
</html>