On Thu, 2009-10-22 at 11:33 -0400, Robert Haas wrote:
> 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?
I think this is a misunderstanding of how effective_cache_size works. I
can't think of any reason to do that. I could see a reason to tell the
OS to not throw a relation into cache but that is a different thing.
Joshua D. Drake
>
> ...Robert
>
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander