[ale] On Databases...

[Jeff Hubbs]

One of the things I'd be interested in examining with both PostgreSQL
and any other similar offering I could get my hands on (and run on
serious OSses too, thereby excluding MS SQL Server) is how to optimize
your drive situation for the app and the task at hand.  

When I took Oracle8i training about a year ago, the instructor talked a
LITTLE about how do use drives but it was clear that she was one of
these DBA/DB coder who really had no experience with hardware.  I feel
like, given a certain DB operation, two DBMSses might compare one way
when you're trying to work a single drive or a single RAID array yet
compare differently when you use two arrays or even two different
controllers.  Suppose your operation reads a bunch of tables and writes
another - you'd want to put all the read tables on one array and the
write table on another and you might make the write array faster than
the read arrays or vice versa depending on whether your operation
created more data than it read.  I know that I designed a WinNT system a
few years back that did reads from one drive and writes to a three-drive
stripe set (this was software RAID) and it wound up running the data
translation software about 30 times faster than the machine it replaced
- and the RAID arrangement was responsible for a lot of that increase.

- Jeff

On Wed, 2002-07-10 at 12:31, Stuffed Crust wrote:
> On Wed, Jul 10, 2002 at 11:15:08AM -0400, Charles Marcus wrote:
> > > Unfortunately, as good as postgresql is, it's relatively
> > > slow..
> > 
> > Huh...  When's the last time you looked at it?  It seems pretty zippy to me.
> 
> The last version I used in production was v7.1.2; I was evaluating v7.2
> when Incanta folded.. it seemed to be about the same speed, but had many
> other features (and bug fixes) that were highly desireable.. like live
> non-locking vacuums.
> 
> While it may be "zippy", that doesn't change the fact that it's still
> relatively slow, certianly compared to the heavy-hitters, but also
> compared to (dare I say it) MySQL, at lest on simple queries. 
> (Meanwhile, I think that MySQL is otherwise mediocre)
> 
> Anyway, I got to use PostgreSQL quite extensively for the better part of
> two years.   It's definately the best you can do without forking over
> gobs of cash... 
> 
> > > and more importantly, it lacks things like database
> > > replication
> > 
> > Really?  www.pgsql.com/press/PR_5.html begs to differ (and this was in
> > 2000).
> 
> http://developer.postgresql.org/todo.php
> 
> The very first entry in the URGENT list:
> 
> *  Add replication of distributed databases
> 
> The rserv stuff is actually quite similar to a tool we developed
> internally.  They're both external programs that watch the database for
> changes, then propogate those changes to another database.    Though our
> tool was considerably more robust...
> 
> But I digress.  The WAL has a lot of potential as the basis of a
> replication system; far better than the trigger-based model
> that Rserve uses. 
> 
> But back to my original point.  Postgresql lacks replication features.
> 
>  - Pizza
> -- 
> Solomon Peachy                                   pizza at f*ckthesuers.org
> I'm not broke, but I'm badly bent.                         ICQ #1318344
> Patience comes to those who wait.                         Melbourne, FL



---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.