Re: A costing analysis tool

Kevin,

> 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.

I'm a little cautious about storing only non-defaults; the defaults have 
changed from version to version, after all.  If we did that, we'd need to 
have a "defaults" table in the db as a reference list.

Also, we'll need to store runtime options both on the "machine" level and 
on the "query" level, in order to allow testing of changing an enable_* or 
other query cost option at runtime.   Not sure how to capture this, 
though.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco