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

From Cédric Villemain
Subject Re: per table random-page-cost?
Date
Msg-id 200910221716.36366.cedric.villemain@dalibo.com
Whole thread Raw
In response to Re: per table random-page-cost?  (Greg Stark <gsstark@mit.edu>)
Responses Re: per table random-page-cost?
Re: per table random-page-cost?
List pgsql-hackers
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 ;)


>
> While this isn't a simple flag to change it does seem like a bit of a
> SMOP. The GUC infrastructure stores these values in global variables
> which the planner and other systems consult directly. They would
> instead have to be made storage parameters which the planner and other
> systems check on the appropriate table and default to the global GUC
> if they're not set.
>



--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: B-tree leaf node structure
Next
From: Pavel Stehule
Date:
Subject: Re: some possible parser cleaning: drop support column(table) syntax