Re: per table random-page-cost? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: per table random-page-cost?
Date
Msg-id 603c8f070910220833t79814e05se5d5d6eb035bc750@mail.gmail.com
Whole thread Raw
In response to Re: per table random-page-cost?  (Cédric Villemain <cedric.villemain@dalibo.com>)
Responses Re: per table random-page-cost?
Re: per table random-page-cost?
List pgsql-hackers
On Thu, Oct 22, 2009 at 11:16 AM, Cédric Villemain
<cedric.villemain@dalibo.com> wrote:
> Le lundi 19 octobre 2009 23:27:20, Greg Stark a écrit :
>> On Mon, Oct 19, 2009 at 2:08 PM, marcin mank <marcin.mank@gmail.com> wrote:
>> > Currently random_page_cost is a GUC. I propose that this could be set
>> > per-table.
>>
>> Or per-tablespace.
>>
>> Yes, I think there are a class of GUCs which describe the physical
>> attributes of the storage system which should be per-table or
>> per-tablespace. random_page_cost, sequential_page_cost,
>> effective_io_concurrency come to mind.
>
> and, perhaps effective_cache_size.
>
> You can have situation where you don't want some tables go to OS memory (you
> can disabled that at filesystem level, ... l'd like to be able to do that at
> postgres level but it is another point)
>
> So you put those tables in a separate tablespace, and tell postgresql that the
> effective_cache_size is 0 (for this tablespace), up to postgres to do the right
> thing with that ;)

Why would you ever want to set effective_cache_size to 0?

...Robert


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: some possible parser cleaning: drop support column(table) syntax
Next
From: Tom Lane
Date:
Subject: Re: some possible parser cleaning: drop support column(table) syntax