> 1. Store each element for a vector in a separate table, and "reconstruct" the > vector when we want the values. This has two side effects. First of all, each > access requires multiple database access, or complex joining of tables which > will increase the access time. Secondly, if each element is stored by itself > it also need to be stored with the ID of the stat it belongs to, the index of > the dump it belongs to and its position within the vector. This potentially > requires more space to store than the approach in this patch. That said, it > would allow only specific elements of the vector to be pulled from the > database. > 2. Manually pack the data into the blob field. We could only store the data > which is non-NaN by manually packing the data so that we store <index within > vector><value as double>. This has the advantage of only storing the data we > care about (although we have the additional overhead of storing the index > within the vector) and we could pull this data out with one database access. > However, we do then have the overhead of packing and unpacking the data which > is potentially very slow and time consuming. > > Personally I don't think that any of these solutions are ideal, but I think > that the solution in the patch presents a fairly foolproof way of storing the > data. Of course, I am more than open to suggestions, but I think it will > always be a trade-off between elegance, size, speed and accuracy.
You should add an index column. It will allow you to build an array. The index is the flattened index into a multidimensional structure. You could also do what I did with the mysql stats, which is have a separate table for each statistic type, then you can have an index column for 1d stats, and x, and y columns for 2d stats. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
