Vlad posted this as a comment (https://bugzilla.mozilla.org/show_bug.cgi?id=387174) but it deserves it's own bug. I've been thinking about a better schema for the graph stuff (since it wasn't really ever designed to do anything with per-run data other than a single point), and came up with something like this: build_info: build_id, machine, branch, description test_info: test_id, type, name, description run_info: run_id, build_id, test_id, time, run_value run_values: run_id, name, index, value run_annotations: run_id, anno_type, annotation Each run corresponds to a specific test on a particular build; each test can produce one or more values. The raw data from the test could be stored as an annotation with anno_type 'json'; user-entered annotations can be stored with a different anno_type. Each test could be frozen; if a test changes, a new test_id is allocated for it (e.g. if the pageset is changed). The run_values table would store all the data (the resulting named indexed arrays) from each test run, and the annotations could be used to store precomputed data (such as the final "Tp" number) so that it can be queried quickly. For example, querying the Tp graph for a particular machine/branch would mean getting all annotations of anno_type 'tp_avg' from every run for every build_id where the machine and branch match the requested data, and where the run test_id is the 'tp' test id. It's a bit more work on the DB side, but it can store all the data for each test without having to ship blobs back and forth. Asking for the data for a particular run would give you back a json blob that includes all the data, plus all the annotations.

Note that I implemented something sort of like this in http://vlad.off.net/hg/graph/file/35edf96f0f4b/server/GraphDB.py

Reassigning to myself for the moment.

Closing, we have a new schema that is very similar to this here: https://wiki.mozilla.org/images/f/f5/Graph_server_new_db_schema.jpg See bug 456528 for implementation & schema questions.