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.villem...@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.m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
