Re: per-tablespace random_page_cost/seq_page_cost

On Mon, Oct 26, 2009 at 11:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
>>> I think a design that is limited to a prespecified set of GUCs is
>>> broken by definition.  It'd be better to make it work like
>>> ALTER DATABASE SET.
>
>> How should that work if there are conflicting settings in two tablespaces when
>> tables from both are used?
>
> Well, most of the settings that would be sensible for this are used in
> cost estimates that are basically per-table or per-index, so I don't
> think it's a huge problem in practice.  But I should clarify my comment:
> the set of GUCs used this way must not be wired into the catalog
> structure.  I think that the code will only pay attention to certain
> GUCs that are valid in-context, but we shouldn't have to redesign the
> catalog each time we add one.

These don't exactly fit into the GUC framework because AIUI a GUC is a
global variable, and the function of the GUC machinery is simply to
make sure that the global variable in question is set to the right
value at the right time. These are really more like reloptions (that
may happen to have the same name as GUCs, I suppose) - always in
effect, but only for a particular object.

I confess that I'm a bit mystified about the design of the reloptions
stuff. It seems kind of odd to store structured data as text[]; it's
kind of the opposite of what I would normally recommend as good
database design.

...Robert