<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,<br>
<br>
<blockquote type="cite">
<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>
</blockquote>
In the ERD, do the flags_tests and runs tables need test_id?<br>
<br>
<blockquote type="cite">The raw_results table is the bottleneck.
We record 200,000+ individual results for a single run, so this
table will get really quickly.</blockquote>
I'm guessing this is the power trace directly from the measurement
board? If so, the fields should be run_id, timestamp and power.<br>
<br>
We may not want to store the entire trace in the database - with
millions of measurements, the database might get unmanagably large
- might be better if the raw_results was just the time, energy,
average power, peak power, etc for that specific run.<br>
<br>
<blockquote type="cite">We could split this out into a different
results table, but it's a one-to-one relationship </blockquote>
The join between tests and runs should be changed from one-to-many
in the diagram to one-to-one.<br>
<br>
<br>
Looks good from the energy measurement side :)<br>
<br>
<br>
James<br>
<br>
On 28/08/13 18:24, Simon Hollis wrote:<br>
</div>
<blockquote cite="mid:521E326A.60608@cs.bris.ac.uk" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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 moz-do-not-send="true"
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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mageec@mageec.org">mageec@mageec.org</a>
<a moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>