Re: Big 7.1 open items - Mailing list pgsql-hackers

From Don Baccus
Subject Re: Big 7.1 open items
Date
Msg-id 3.0.1.32.20000616111435.01a17a10@mail.pacifier.com
Whole thread Raw
In response to Re: Big 7.1 open items  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
Responses Re: Big 7.1 open items
List pgsql-hackers
At 04:27 PM 6/16/00 +0000, Thomas Lockhart wrote:

>Sorry for being behind here, but to make sure I'm on the right page:
>o tablespaces decouple storage from logical tables
>o a database lives in a default tablespace, unless specified
>o by default, a table will live in the default tablespace
>o (eventually) a table can be split across tablespaces

Or tablespaces across filesystems/mountpoints whatever.

>Some thoughts:
>o the ability to split single tables across disks was essential for
>scalability when disks were small. But with RAID, NAS, etc etc isn't
>that a smaller issue now?

Yes for size issues, I should think, especially if you have the 
money for a large RAID subsystem.  But for throughput performance,
control over which spindles particularly busy tables and indices
go on would still seem to be pretty relevant, when they're being
updated a lot.  In order to minimize seek times.

I really can't say how important this is in reality.  Oracle-world
folks still talk about this kind of optimization being important,
but I'm not personally running any kind of database-backed website
that's busy enough or contains enough storage to worry about it.

>o "tablespaces" would implement our less-developed "with location"
>feature, right? Splitting databases, whole indices and whole tables
>across storage is the biggest win for this work since more users will
>use the feature.
>o location information needs to travel with individual tables anyway.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: planner question re index vs seqscan
Next
From: Don Baccus
Date:
Subject: Re: Big 7.1 open items