On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Arguably, you would expect parameters set using this syntax to be
> stored similar to reloptions - that is, as text[].  But as we're going
> to need these values multiple times per table to plan any non-trivial
> query, I don't want to inject unnecessary parsing overhead and code
> complexity.

Two comments, perhaps complementary, though I'm not sure of either answer.

1 Would we rather the storage scheme allow for future GUCs to be
easily moved to per-tablespace as well without changing the catalog
schema for every option? (Someone might accuse me of trolling the
anti-EAV people here though...)

2 Would it make sense to slurp these options from the tablespace
options into the relcache when building the relcache entry for a
table? That would make the storage format in the tablespace options
much less relevant. It might even make the catcache less important
too.

-- 
greg

In response to

• per-tablespace random_page_cost/seq_page_cost at 2009-10-25 16:05:54 from Robert Haas

pgsql-hackers by date

Next:	From: Jaime Casanova	Date: 2009-10-26 16:15:09
	Subject: Re: License clarification: BSD vs MIT
Previous:	From: David E. Wheeler	Date: 2009-10-26 16:08:22
	Subject: Re: [ANNOUNCE] PostgreSQL 8.5alpha2 Now Available