I would like to see some tool that reported an semi-accurate value for random page cost before adding the value per tablespace.
--------------------------------------------------------------------------- Scott Marlowe wrote: > On Thu, 2004-07-01 at 18:54, Gavin Sherry wrote: > > On Thu, 1 Jul 2004, Mike Rylander wrote: > > > > > On Thursday 01 July 2004 06:43 pm, Gavin Sherry wrote: > > > > Hi Mike, > > > > > > > > In this release, unfortunately not. > > > > > > That't too bad, but it's not that urgent I suppose. > > > > > > > > > > > I had some idea early on of putting rand_page_cost in pg_tablespace and > > > > having the planner have access to it for costing. I didn't actually get > > > > around to it but. :-( > > > > > > Well, I haven't looked at the PG source before, but if you have some specific > > > design ideas I would be glad to help out. I'm just not sure where (or when, > > > with the official release coming (sort of) soon) to start, but with some > > > pointers I'll do what I can! > > > > Well, it wont be in 7.5. Feel free to start looking at how > > random_page_cost in cost_index(). It might be worthwhile introducing a per > > tablespace performance factor so that we could could say that the cost of > > fetching an index tuple from tablespace A is half that of fetching an > > index tuple from tablespace B. That idea might not actually turn out to be > > a very good one once I look at it closely though. > > How about having a per cluster / database / tablespace / table type > setup that goes in a hierarchy, if they're there. I.e. if the database > doesn't have it's own random_page_cost, it inherits from cluster, if a > tablespace doesn't have one, it inherits from cluster->database, and so > on to individual tables / indexes. It may be that it's easier to > implement for them all now while doing it for tablespaces. Just > wondering. I'm a user, not a hacker, so I have no idea how much that > idea makes any sense, but I would certainly love to be able to set an > index to have a random_page_cost effect of 1.1 while the table it lives > in is 1.3, the tablespace 1.4, and so on. But not required, because it > always inherits from the parent if it doesn't have one, like stats > target. > > > > !DSPAM:40e4b98b142131356954127! > > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match