Re: Quick question regarding tablespaces

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Scott Marlowe <smarlowe(at)qwest(dot)net>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Mike Rylander <miker(at)purplefrog(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Quick question regarding tablespaces
Date: 2004-07-06 12:22:24
Message-ID: 200407061222.i66CMOA01012@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-06 13:36:25 Re: More thoughts on drop tablespace
Previous Message Andrew Dunstan 2004-07-06 12:09:23 Re: [Plperlng-devel] strange bug in plperl