Re: SV: MySQL and PostgreSQL speed compare - Mailing list pgsql-general

From Gordan Bobic
Subject Re: SV: MySQL and PostgreSQL speed compare
Date
Msg-id 006c01c074a5$cc393160$8000000a@localdomain
Whole thread Raw
In response to SV: MySQL and PostgreSQL speed compare  ("Jarmo Paavilainen" <netletter@comder.com>)
List pgsql-general
> Advanced tools do have advanced safety features, but are sold "ready
> for most use", not "safely disabled until you read all of the manuals
> so you can figure out how to make it work decently". I agree that
> reading the manuals is an important part of learning a new tool,
> but it shouldn't be *required* to make it work for basic use.

It isn't *required*. It works lovely the way it is shipped. But if you want
more speed, you should go and read the manual before complaining. It is not
crippled in any way - just tuned on the side of caution. It STILL works
well for MOST users who just want something to work, rather than ultimate
speed or reliability. It is up to the user to decide what is more important
for their particular application, and what is more appropriate given their
setup and budget.

> Users shouldn't have to know how to tune the fuel injection system
> for *optimum* performance in order to take a car for a test drive
> on a fast roadway.

No, they shouldn't. However, for THOSE users, the more appropriate way of
solving the problem would be to buy faster hardware - this is the analogy
you are following, right? If you want to drive faster than the car will let
you, buy a faster car, right?

> Computer software is, indeed, a tool which does not do everything
> for you. But is should come "from the factory" setup for the way
> a user would expect it to run, not partially disabled for maximum
> safety.

It is not "disabled" in any way. It works very well, for a vast majority of
uses. If you are setting up a web site, which you want people to see, then
you should consider yourself serious enough to read the documentation. If
you are intending to stake the future of your business on a server, then
exactly what are you thinking if you still refuse to RTFM?

> It's a power tool, and it can "hurt" if misused. If that's
> too much responsibility for a bad user, it won't matter how safely
> it's been tuned at the factory, the bad user will *still* modify it
> in unsafe ways, and often tune it or use it the wrong way, damaging
> the tool in the process.

There is a valid point in there somewhere. However, there is nothing wrong
with erring on the side of caution. All the functionalityis there - but if
you need more speed, all it takes is reading through the archives for an
hour or so, and you will find all the answers you need.

> I don't expect my software to come optimized for my use. I expect
> it to come optimized for the most users and uses, not "dumbed down"
> for the worst case, or "safely disabled" for the worst users.

Why? What's your reasoning behind that? If all the functionality is there,
and the only penalty is speed, which is still adequate for most uses, what
is the problem? If you are happy with tuning things up for your particular
application, they the chances are that you will go through the tuning
process yourself regardless of how it is shipped. All the default that is
slightly slower will do is encourage you to read the docs that little bit
sooner, if your system becomes large enough for this to be an issue.

Regards.

Gordan


pgsql-general by date:

Previous
From: "Gordan Bobic"
Date:
Subject: Re: How passwords can be crypted in postgres?
Next
From: Jens Hartwig
Date:
Subject: Re: How passwords can be crypted in postgres?