At 08:23 PM 1/13/00 -0500, Tom Lane wrote:
>As far as the actual implementation goes, the low level access methods
>go through a "storage manager" switch that was intended to allow for
>the addition of a new storage manager, such as a raw-device manager.
>So you could get a good deal of stuff working by implementing code that
>parallels md.c/fd.c. The main problem at this point is that there is a
>fair amount of utility code that goes out and does its own manipulation
>of the database file structure. You'd need to clean that up by pushing
>it all down below the storage manager switch (inventing new storage
>manager calls as needed).
This would need to be done to implement some sort of tablespace-style
facility, too, right? I'm off Xun's thread in asking but I've been
wondering. DBs like Oracle allow you to place tables and indices
whereever you like in the filesystem. This is normally done to
distribute things across different spindles, and in large, busy
databases makes a significant difference. I've done some experimenting
moving index files to a different spindle (using "ln" to fool
postgres, of course) and insertions go measurably faster. Spindles
are so cheap nowadays :)
I know there's been discussion of letting folks specify where the
WAL will be placed when it's implemented, for safety's sake - it
will also improve performance.
>You don't get to do either of the latter two unless you write a
>raw-device storage manager
Not within a single filesystem, but scattering things across spindles
could be done without a raw-device storage manager :)
(not what he's talking about, but heck, thought I'd raise it)
- 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.
