Re: [HACKERS] [hackers]development suggestion needed

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: xun(at)cs(dot)ucsb(dot)edu (Xun Cheng), pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] [hackers]development suggestion needed
Date: 2000-01-14 02:19:33
Message-ID: 3.0.1.32.20000113181933.010771d0@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-01-14 02:20:56 Re: [HACKERS] [hackers]development suggestion needed
Previous Message Tom Lane 2000-01-14 02:10:30 Re: Peter opens a can of worms