On Monday 19 February 2007 11:27, Martijn van Oosterhout wrote:
> On Mon, Feb 19, 2007 at 05:10:36PM +0100, Dimitri Fontaine wrote:
> > > RAID and LVM too.  I can't get excited about re-inventing those wheels
> > > when perfectly good implementations already exist for us to sit on top
> > > of.
> >
> > I though moving some knowledge about data availability into PostgreSQL
> > code could provide some valuable performance benefit, allowing to
> > organize reads (for example parallel tables scan/indexes scan to
> > different volumes) and obtaining data from 'quicker' known volume (or
> > least used/charged).
> Well, organising requests to be handled quickly is a function of
> LVM/RAID, so we don't go there. However, speeding up scans by having
> multiple requests is an interesting approach, as would perhaps a
> different random_page_cost for different tablespaces.

On one of my systems I have 1 tablespace for read data (99-1), 1 for read 
mostly data (90-10), and 1 for write mostly (40-60).  The breakdown is based 
on a combination of the underlying hardware and usage patterns of the tables 
involved. I suspect that isn't that uncommon really.  I've often thought that 
being able to set guc variables to a specific tablespace (like you can do for 
users) would allow for a lot of flexibility in tuning queries that go across 
different tablespaces. 

Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to