per table random-page-cost?
in [PgSql]
|
From: Tom Lane on 19 Oct 2009 18:33 marcin mank <marcin.mank(a)gmail.com> writes: > I thought about making it per-table, but realistically I think most > people don`t use tablespaces now. I would not want to be telling > people "to be able to hint the planner to (not) index-scan the table, > You must move it to a separate tablespace". Per-table is not physically sensible. Per-tablespace has some rationale to it. regards, tom lane -- 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: Andrew Dunstan on 19 Oct 2009 18:45 marcin mank wrote: >> I've been thinking about this a bit, too. I've been wondering if it >> might make sense to have a "random_page_cost" and "seq_page_cost" >> setting for each TABLESPACE, to compensate for the fact that different >> media might be faster or slower, and a percent-cached setting for each >> table over top of that. >> >> > > I thought about making it per-table, but realistically I think most > people don`t use tablespaces now. I would not want to be telling > people "to be able to hint the planner to (not) index-scan the table, > You must move it to a separate tablespace". > This is just plain wrong, in my experience. *Every* large installation I deal with uses tablespaces. This proposal is just "hints by the back door", ISTM. As Tom says, there is a justification for having it on tablespaces but not on individual tables. If you want to argue for full blown planner hints, that's a whole other story. Have you read the previous debates on the subject? cheers -- 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: marcin mank on 19 Oct 2009 19:04 > This proposal is just "hints by the back door", ISTM. As Tom says, there is > a justification for having it on tablespaces but not on individual tables. If the parameter is defined as "the chance that a page is in cache" there is very real physical meaning to it. And this is per-table, not per-tablespace. A "users" table will likely be fetched from cache all the time, while a "billing_records" table will be fetched mostly from disk. Greetings Marcin -- 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: Tom Lane on 19 Oct 2009 19:21 marcin mank <marcin.mank(a)gmail.com> writes: >> This proposal is just "hints by the back door", ISTM. As Tom says, there is >> a justification for having it on tablespaces but not on individual tables. > If the parameter is defined as "the chance that a page is in cache" > there is very real physical meaning to it. We have no such parameter... regards, tom lane -- 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 19 Oct 2009 19:29
On Mon, Oct 19, 2009 at 4:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > marcin mank <marcin.mank(a)gmail.com> writes: >>> This proposal is just "hints by the back door", ISTM. As Tom says, there is >>> a justification for having it on tablespaces but not on individual tables. > >> If the parameter is defined as "the chance that a page is in cache" >> there is very real physical meaning to it. > > We have no such parameter... And we want our parameters to be things the DBA has a chance of being able to estimate. How would you come up with sensible figures for this hypothetical parameter? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |