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