Re: patch - per-tablespace random_page_cost/seq_page_cost

Robert Haas <robertmhaas@gmail.com> writes:
> ....  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.

The same, until it's different.  There is no reason at all to suppose
that the set of options people will want to apply to a tablespace will
remain constant over time --- in fact, I don't think there's even a
solid consensus right now on which GUCs people would want to set at the
tablespace level.  I don't believe it is wise to hardwire this into the
catalog schema.  Yes, it would look marginally nicer from a theoretical
standpoint, but we'd be forever having to revise the schema, plus a lot
of downstream code (pg_dump for example); which is not only significant
work but absolutely prevents making any adjustments except at major
version boundaries.  And I don't see any concrete benefit that we get
out of a hardwired schema for these things.  It's not like we care about
optimizing searches for tablespaces having a particular option setting,
for example.
        regards, tom lane