Re: [HACKERS] [hackers]development suggestion needed

At 10:43 PM 1/13/00 -0500, Mike Mascari wrote:

>For example, if several disk drives are available to store the
>database, it might be helpful to store table data in a tablespace
>on one disk drive, and index data in a tablespace on another disk
>drive.

My gosh, imagine - I didn't just make this up! The amazement :)

> This way, when users query table information, both disk
>drives can work simultaneously, retrieving table and index data
>at the same time.

Overlapped Disk I/O - I remember that term from way back in my
(gulp) PDP-8 days, working as a system hacker...

Look - in case there's any doubt, I'm not trying to toast Postgres,
I'm a fan, interested in getting more involved in the development
scenario. I raised this issue because Xun raised some "really big
database issues which I as a database theorist have an interest in".
My biggest sin if any is to try to paint the horizon, at this point.
Philip Greenspun still says that those of us (including employee
#3 or so of his company, Ben) who are interested in Postgres are "losers"
by definition (Ben no longer works there). Meanwhile, folks like Ben
and I keep telling folks that Postgres is growing into an ideal
RDBMS for database-backed websites (you know, that place where all
money is flowing and will continue to do so tomorrow, though don't
ask me about next week? :) And Philip says you're a loser if you
won't pay Oracle's license fee. He speaks as a dude badly bitten
by Illustra, based long ago on a long-dead version of Postgres but
the pain not yet forgotten...

Things like the Oracle documentation cited above fall into the class
of advice to folks running really big - and REALLY BUSY - database
servers.

Sure, hardware (cycles, RAM) fallsin price and as time goes on we
can perhaps forget some of the more horrific optimization stuff that
was invented to deal with small computer systems of one decade ago.

As a compiler writer, trust me - I'm familiar with the concept. And
with changing pardigms as designs flow from CISC to RISC (oh gosh,
not a theoretical advantage but you mean just a cost/performance point
on the transistor-per-chip curve? Damn, I should've patented my
cynicism 10 years ago!) and back to post-RISC CISC, I'm not about
to claim theoretical long-term advantages for any point-of-view.

I won't suggest that all of the big-time hacks employed to make old
commercial DBs like Oracle are necessary in today's hardware/OS climate
(raw I/O in particular falls into that category, IMH-tentative-O)

But, still...as long as we've had movable head disk drives (and my
first disk drive was head-per-track, believe it or not) minimizing
head movement has been an optimization goal. I've written complex
scheduling disk drivers in the past, and they can be good. Still,
nothing beats coalescing one spindle's I/O into a narrow number of
tracks, minimizing head movement. That's a constant that hasn't
changed for 30 years, and won't change next week.

Heck, it even lowers your downtime due to blown drives.

I might also add that the kind of systems Oracle doc writers were
thinking of 10 years ago just aren't in the Postgres universe of
possible DB clients...

But, it is changing. One impact - like it or not - of the good work
you folks have done over the past couple of (3 or 4 or I'm not personally
sure how much) years and the fact that you continue to push the db into
being more and more capable, more and more stable, more and more
feature-filled with SQL-92 stuff is that folks being asked to pay
$25,000 for a fully-paid up license on a PIII500 X86 system (<$2000
in hardware without even shopping, a greater than 10-1 software to
hardware ratio) are going to be looking for a cheaper alternative.

Of which you folks are one.

So, what's the deal, here...is the goal the Big Time or not?

- 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.