Re: patch - per-tablespace random_page_cost/seq_page_cost

On Sat, Nov 14, 2009 at 3:06 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Sat, Nov 14, 2009 at 7:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I ended up not reusing the reloptions.c code.  It looks like a lot of
>> extra complexity for no obvious benefit, considering that there is no
>> equivalent of AMs for tablespaces and therefore no need to support
>> AM-specific options.  I did reuse the reloptions syntax, and I think
>> the internal representation could always be redone later, if we find
>> that there's a use case for something more complicated.
>
> a) effective_io_concurrency really deserves to be in the list as well.
>
> b) I thought Tom came down pretty stridently against any data model
> which hard codes a specific list of supported options. I can't
> remember exactly what level of flexibility he wanted but I think
> "doesn't require catalog changes to add a new option" might have been
> it.
>
> I agree that having everything smashed to text is a bit kludgy though.
> I'm not sure we have the tools to do much better though.

I'm hoping Tom will reconsider, or at least flesh out his thinking.
What the reloptions code does is create a general framework for
handling options.  Everything gets smashed down to text[], and then
when we actually need to use the reloptions we parse them into a C
struct appropriate to the underlying object type.  This is really the
only feasible design, because pg_class contains multiple different
types of objects - in particular, tables and indices - and indices in
turn come in multiple types, depending on the AM.  So the exact
options that are legal depend on the the type of object, and for
indices the AM, and we populate a *different* C struct depending on
the situation.  pg_tablespace, on the other hand, only contains one
type of object: a tablespace.  So, if we stored the options as text[],
we'd parse them out into a C struct just as we do for pg_class, but
unlike the pg_class case, it would always be the *same* C struct.

In other words, we CAN'T use dedicated columns for pg_class because we
can't know in advance precisely what columns will be needed - it
depends on what AMs someone chooses to load up.  For pg_tablespace, we
know exactly what columns will be needed, and the answer is exactly
those options that we choose to support, because tablespaces are not
extensible.

That's my thinking, anyway...  YMMV.

...Robert