Re: [HACKERS] [hackers]development suggestion needed - Mailing list pgsql-hackers

From Don Baccus
Subject Re: [HACKERS] [hackers]development suggestion needed
Date
Msg-id 3.0.1.32.20000113181933.010771d0@mail.pacifier.com
Whole thread Raw
In response to Re: [HACKERS] [hackers]development suggestion needed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Multiple Spindles ( Was: Re: [HACKERS] [hackers]development suggestion needed )
Re: [HACKERS] [hackers]development suggestion needed
List pgsql-hackers
At 09:01 PM 1/13/00 -0500, Tom Lane wrote:

>As you say, you can fake it manually with symbolic links, but that's
>a kluge.

Yes, it is.  Or worse :)
>
>The "database location" stuff that Peter and Thomas have been arguing
>about is intended to allow a single postmaster to control databases that
>are in multiple physical locations --- but there seems to be some debate
>as to whether it works ;-).  (I never tried it.)  In any case, we don't
>currently have any official provision for controlling location at finer
>than database level.  It'd be nice to be able to push individual tables
>around, I suppose.

Putting indices on different spindles than the tables is known to
significantly speed up the Ars Digita Community system under load
with Oracle.  Systems like this, used to back busy web sites, stuff
things into tables many times a second.  As I mentioned, I've played
around a bit with postgres using "ln" and it does indeed help boost
the number of inserts my (paltry, two-spindle) system could sustain.

The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.

My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become.  Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.

>
>This wouldn't require a new storage manager, since presumably you'd
>still be using the Unix-filesystem storage manager.  The trick would be
>to allow a path rather than just a base file name to be specified
>per-relation.  I'm not sure if it'd be hard or not.  Probably, all the
>system tables would have to stay in the database's default directory,
>but maybe user tables could be given path names without too much
>trouble...

I've looked into it, actually, and have reached the same conclusion.
Including the bit about keeping system tables in the database's default
directory.



- 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: Peter opens a can of worms
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] [hackers]development suggestion needed