From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A costing analysis tool |
Date: | 2005-10-19 18:05:34 |
Message-ID: | 4356449E0200002500000135@gwmta.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Maybe we could associate a set of defaults to runtime_environment,
and you would associate any overrides with the runtime_options.
Does this address both your concerns?
>>> Josh Berkus <josh(at)agliodbs(dot)com> >>>
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-10-19 18:15:20 | Re: A costing analysis tool |
Previous Message | Robert Treat | 2005-10-19 18:01:40 | Re: A costing analysis tool |