Re: patch - per-tablespace random_page_cost/seq_page_cost - Mailing list pgsql-hackers

On Sat, Nov 14, 2009 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I can tell I've lost this argument, but I still don't get it.  Why do
we care if we have to change the schema?  It's not a lot of work, and
the number of times we would likely bump catversion for new
pg_tablespace options seems unlikely to be significant in the grand
scheme of things.  I don't think there are very many parameters that
make sense to set per-tablespace.  As for major version boundaries, it
seems almost unimaginable that we would backpatch code to add a new
tablespace option whether the schema permits it or not.  Can you
clarify the nature of your concern here?

What I'm concerned about with text[] is that I *think* it's going to
force us to invent an analog of the relcache for tablespaces.  With
hardwired columns, a regular catcache is all we need.  But the
reloptions stuff is designed to populate a struct, and once we
populate that struct we have to have someplace to hang it - or I guess
maybe we could reparse it on every call to cost_seqscan(),
cost_index(), genericcostestimate(), etc, but that doesn't seem like a
great idea.  So it seems like we'll need another caching layer sitting
over the catcache.  If we already had such a beast it would be
reasonable to add this in, but I would assume that we wouldn't want to
add such a thing without a fairly clear use case that I'm not sure we
have.  Maybe you see it differently?  Or do you have some idea for a
simpler way to set this up?

...Robert