Re: A costing analysis tool
От | Kevin Grittner |
---|---|
Тема | Re: A costing analysis tool |
Дата | |
Msg-id | 4356449E0200002500000135@gwmta.wicourts.gov обсуждение исходный текст |
Ответ на | A costing analysis tool ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | 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@agliodbs.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.
В списке pgsql-hackers по дате отправления: