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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073