Re: per-tablespace random_page_cost/seq_page_cost

On Tue, Oct 27, 2009 at 9:20 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> > 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.
>>
>> It's definitely a bit EAV-ish :-(.  But I don't see any particularly
>> easy way to modify it to store bool/int/float parameters in their
>> native types; do you?
>
> More columns, each of the correct type, with the table constraint that
> at most one may be populated is how I handle stuff like that.

I don't see why we'd need to constrain more than one from being
populated, but yeah, that's basically what I was thinking: one column
per parameter, of the appropriate type. That might not be such a good
model if the number of possible options was really large, but at this
point there's no reason to believe that will be the case for either
reloptions or the proposed spcoptions.

For things like autovacuum options, the actual representation probably
doesn't matter much because I'm guessing that the amount of work being
done by vacuum dwarfs the parsing cost, and it's a background task
anyway. But this seems like a less solid argument for things like
fillfactor and the proposed per-tablespace
seq_page_cost/random_page_cost, which will be accessed by many queries
and in the latter case often more than once. Ideally (or so it seems
to me) you'd like to fetch those things out of Form_pg_whatever rather
than parsing text strings to get at 'em.

...Robert