From: | Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, marcin mank <marcin(dot)mank(at)gmail(dot)com> |
Subject: | Re: per table random-page-cost? |
Date: | 2009-10-22 15:16:31 |
Message-ID: | 200910221716.36366.cedric.villemain@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)mank(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-10-22 15:30:41 | Re: some possible parser cleaning: drop support column(table) syntax |
Previous Message | Tom Lane | 2009-10-22 15:14:36 | Re: B-tree leaf node structure |