Summary of schema I'm considering. Comments welcome. When it gets downt to the detail, it may make sense to combine or split some of these. For example, runtime_options should probably not have a column for each currently known option, but a child table which maps to all non-default option values.
submitter Identifies who submitted test results. Name, optional info such as email address and organization runtime_environment Identifies the overall test environment. OS with distribution & version, CPU number, type speed, RAM, background load, static configuration, etc. This provides context for a series of tests, to see how the numbers look in a given environment dataset_characteristics Identifies data metrics which may affect costing accuracy Table counts, row counts, column counts, disk space used, level of fragmentation. Maybe some of the "standard" tests will share common dataset characteristics across multiple environments. cache_state Identifies the level of initial caching for a test, and the degree to which the referenced data can be cached during execution runtime_options Identifies the runtime choices in effect for a query run. The state of EXPLAIN, ANALYZE, enable_xxx, and dynamic configuration settings, such as random_page_cost. query Identifies a test query, possibly run by many people in many environments against various datasets with different cache states and runtime options test_result_summary Ties a query to details about a run, with a summary of results. Run time from the client perspective, rows returned. test_result_step_detail Shows EXPLAIN ANALYZE information (if any) for each step. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match