That would be something that I'd like to see.  Being new to PostgreSQL some
of the basics of tuning the database were a little hard to find.  The reason
people go with MySQL is because it's fast and easy to use.  That's why I had
been using it for years.  Then when a problem came along and I couldn't use
MySQL I checked out PostgreSQL and found that it would fill the gap, but I
had been able to get by on doing very little in terms of administration for
MySQL (which performed well for me) and I was expecting PostgreSQL to be
similar.  As with many people I have the hat of DB admin, server admin,
programmer and designer and the less I have to do in any of those areas
makes my life a lot easier.

When I first started using PostgreSQL I installed it and entered my data
without any thought of having to tune it because I never had to before.  If
there were some program that could be inserted to the end of the make
process or something it might help dimwits like me :-) realize that there
was more that needs to be done once the installation has been completed.


----- Original Message ----- 
From: "Shridhar Daithankar" <[EMAIL PROTECTED]>
Sent: Friday, July 04, 2003 10:28 AM
Subject: Re: [PERFORM] PostgreSQL vs. MySQL

> On Friday 04 July 2003 20:56, Andrew Sullivan wrote:
> > On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> > > I see this as a major problem.  How many people run postgres, decide
> > > too slow and give up without digging into the documentation or coming
> > > this group?  This seems to be pretty common.  Even worst, they tell 10
> > > others how slow Postgres is and then it gets a bad reputation.
> >
> > There have been various proposals to do things of this sort.  But
> > there are always problems with it.  For instance, on many OSes,
> > Postgres would not run _at all_ when you first compiled it if its
> > defaults were set more agressively.  Then how many people would
> > complain, "It just doesn't work," and move on without asking about
> > it?
> There was a proposal to ship various postgresql.conf.sample like one for
> servers, one for medium, one for update intensive purpose etc.
> I was thinking over it. Actaully we could tweak initdb script to be
> interactiev and get inputs from users and tune it accordingly. Of course
> would be nowhere near the admin reading the docs. but at least it won't
> flat on performance groundas the way falls now.
>  Shridhar
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to