per table random-page-cost?
in [PgSql]
|
From: Josh Berkus on 22 Oct 2009 14:28 All, Wouldn't per *tablespace* costs make more sense? --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 22 Oct 2009 14:41 Greg Stark <gsstark(a)mit.edu> wrote: > There is another use case which perhaps needs to be addressed: if > the user has some queries which are very latency sensitive and > others which are not latency sensitive. Yes. Some products allow you to create a named cache and bind particular objects to it. This can be used both to keep a large object with a low cache hit rate from pushing other things out of the cache or to create a pseudo "memory resident" set of objects by binding them to a cache which is sized a little bigger than those objects. I don't know if you have any other suggestions for this problem, but the named cache idea didn't go over well last time it was suggested. In all fairness, PostgreSQL does a good enough job in general that I haven't missed this feature nearly as much as I thought I would; and its absence means one less thing to worry about keeping properly tuned. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 22 Oct 2009 14:48 On Thu, Oct 22, 2009 at 2:28 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > All, > > Wouldn't per *tablespace* costs make more sense? > > --Josh Yes, we already had several votes in favor of that approach. See upthread. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 22 Oct 2009 16:25 Well I think we need sone way to accomplish the same high level goal of guaranteeing response times for latency-critical queries. However my point is that cache policy is an internal implementation detail we don't want to expose in a user interface. -- Greg On 2009-10-22, at 11:41 AM, "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov > wrote: > Greg Stark <gsstark(a)mit.edu> wrote: > >> There is another use case which perhaps needs to be addressed: if >> the user has some queries which are very latency sensitive and >> others which are not latency sensitive. > > Yes. Some products allow you to create a named cache and bind > particular objects to it. This can be used both to keep a large > object with a low cache hit rate from pushing other things out of the > cache or to create a pseudo "memory resident" set of objects by > binding them to a cache which is sized a little bigger than those > objects. I don't know if you have any other suggestions for this > problem, but the named cache idea didn't go over well last time it was > suggested. > > In all fairness, PostgreSQL does a good enough job in general that I > haven't missed this feature nearly as much as I thought I would; and > its absence means one less thing to worry about keeping properly > tuned. > > -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 22 Oct 2009 19:08
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(a)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(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |