Re: A costing analysis tool

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
lookin 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
characteristicsacross 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,
anddynamic 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.