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

From Greg Stark
Subject Re: per-tablespace random_page_cost/seq_page_cost
Date
Msg-id 407d949e0910260909n3c0ef06dp5ad2eba4cedf1103@mail.gmail.com
Whole thread Raw
In response to per-tablespace random_page_cost/seq_page_cost  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: [ANNOUNCE] PostgreSQL 8.5alpha2 Now Available
Next
From: Jaime Casanova
Date:
Subject: Re: License clarification: BSD vs MIT