[MAGEEC] Structure of the Results Database

[Simon Hollis]

Hi Ashley,

Thanks very much for starting this discussion. This is a really good 
starting point.

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.

As I see it there are at least three interests we need to support: 
Energy Measurement; the MAGEEC framework; ML.

Perhaps all sides could outline the suitability of the proposed 
structure for their needs?

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 
mageec at mageec.org mailing list. Please do so!


On 28/08/13 17:21, Ashley Whetter wrote:
> Hey everyone,
>
> At the last meeting we looked at the ER diagram 
> (http://mageec.org/wiki/Database) for the database that would store 
> the results that would be recorded by the test framework and used by 
> the plugin.
>
> I've taken some of the comments made at the meeting and made a more 
> detailed ER diagram to discuss. 
> (http://mageec.org/w/images/1/19/Results_ERD_Proposal.png)
>
> A test (and test id) refers to a single combination of a platform, 
> compiler, benchmark, and flag set.
> A run (and run id) refers to a single run of a test. A test can have 
> multiple runs.
>
> 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.
>
> 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.
>
> The raw_results table is the bottleneck. We record 200,000+ individual 
> results for a single run, so this table will get really quickly.
>
>
> Ashley
>
>
> _______________________________________________
> mageec mailing list
> mageec at mageec.org
> http://mageec.org/cgi-bin/mailman/listinfo/mageec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mageec.org/pipermail/mageec/attachments/20130828/9b46417a/attachment.html>