Skip site navigation (1) Skip section navigation (2)

Re: per-tablespace random_page_cost/seq_page_cost

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: per-tablespace random_page_cost/seq_page_cost
Date: 2009-10-26 16:09:27
Message-ID: 407d949e0910260909n3c0ef06dp5ad2eba4cedf1103@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group