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
