Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

On Fri, 6 Dec 2002, Thomas O'Connell wrote:

> I was surprised, for instance, to receive a non-list email announcing
> the release of the software but then to have to wait for days actually
> to see it show up on the official (or even the advocacy) website in a
> news item. Even now it is not listed at PostgreSQL, Inc.

ack, an oversight, I can assure you ... I have proded the apporpriate ppl
for this one :(

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Devrim G?ND?Z wrote:
> I do NOT like hearing about MySQL in this (these) list(s).
> 
> PostgreSQL is not in the same category with MySQL. MySQL is for
> *dummies*, not database admins. I do not even call  it a database. I
> have never forgotten my data loss 2,5 years ago; when I used MySQL for
> just 2 months!!! 

I think you're on to something here, but it's obscured by the way you
said it.

There's no question in my mind that PostgreSQL is superior in almost
every way to MySQL.  For those of us who are technically minded, it
boggles the mind that people would choose MySQL over PostgreSQL.  Yet
they do.  And it's important to understand why.

Simply saying "MySQL has better marketing" isn't enough.  It's too
simple an answer and obscures some issues that should probably be
addressed.

People use MySQL because it's very easy to set up, relatively easy to
maintain (when something doesn't go wrong, that is), is very well
documented and supported, and is initially adequate for the task they
have in mind (that the task may change significantly such that MySQL
is no longer adequate is something only those with experience will
consider).

PostgreSQL has come a long way and, with the exception of a few minor
things (the need to VACUUM, for instance.  The current version makes
the VACUUM requirement almost a non-issue as regards performance and
availability, but it really should be something that the database
takes care of itself), is equivalent to MySQL in the above things
except for documentation and support.

MySQL's documentation is very, very good.  My experience with it is
that it's possible, and relatively easy, to find information about
almost anything you might need to know.

PostgreSQL's documentation is good, but not quite as good as MySQL's.
It's not quite as complete.  For instance, I didn't find any
documentation at all in the User's Guide or Administrator's Guide on
creating tables (if I missed it, then that might illustrate that the
documentation needs to be organized slightly differently).  I did find
a little in the tutorial (about the amount that you'd want in a
tutorial), but to find out more I had to go to the SQL statement
reference (in my case I was looking for the means by which one could
create a constraint on a column during table creation time).

The reason this is important is that the documentation is *the* way
people are going to learn the database.  If it's too sparse or too
disorganized, people who don't have a lot of time to spend searching
through the documentation for something may well decide that a
different product (such as MySQL) would suit their needs better.

The documentation for PostgreSQL improves all the time, largely in
response to comments such as this one, and that's a very good thing.
My purpose in bringing this up is to show you what PostgreSQL is up
against in terms of widespread adoption.

> If we want to "sell" PostgreSQL, we should talk about, maybe, Oracle.
> I have never took care of MySQL said. I just know that I'm running
> PostgreSQL since 2,5 years and I only stopped it "JUST" before upgrades
> of PostgreSQL. It's just *working*; which is unfamiliar to MySQL
> users. 

The experience people have with MySQL varies a lot, and much of it has
to do with the load people put on it.  If MySQL were consistently bad
and unreliable it would have a much smaller following (since it's not
in a monopoly position the way Microsoft is).

But you're mistaken if you believe that MySQL isn't competition for
PostgreSQL.  It is, because it serves the same purpose: a means of
storing information in an easily retrievable way.

Selling potential MySQL users on PostgreSQL should be easier than
doing the same for Oracle users because potential MySQL users have at
least already decided that a free database is worthy of consideration.
As their needs grow beyond what MySQL offers, they'll look for a more
capable database engine.  It's a target market that we'd be idiots to
ignore, and we do so at our peril (the more people out there using
MySQL, the fewer there are using PostgreSQL).

> I'm a Linux user. I'm happy that PostgreSQL does not have win32 version.
> If someone wants to use a real database server, then they should install
> Linux (or *bsd,etc). This is what Oracle offers,too. Native Windows
> support will cause some problems; such as some dummy windows users will
> begin using it. I do not believe that PostgreSQL needs native windowz
> support. 

I hate to break it to you (assuming that I didn't misunderstand what
you said), but Oracle offers a native Windows port of their database
engine, and has done so for some time.  It's *stupid* to ignore the
native Windows market.  There are a lot of people who need a database
engine to store their data and who would benefit from a native Windows
implementation of PostgreSQL, but aren't interested in the additional
burden of setting up a Linux server because they lack the money, time,
or expertise.

> So, hackers (I'm not a hacker) should decide whether PostgreSQL should
> be used widely in real database apps, or it should be used even by dummy
> users?

What makes you think we can't meet the needs of both groups?  The
capabilities of PostgreSQL are (with very few exceptions) a superset
of MySQL's, which means that wherever someone deploys a MySQL server,
they could probably have deployed a PostgreSQL server in its place.
It should be an easy sell: they get a database engine that is
significantly more capable than MySQL for the same low price!

Selling to the Oracle market is going to be harder.  The capabilities
of Oracle are a superset of those of PostgreSQL.  Shops which plan to
deploy a database server and who need the capabilities of PostgreSQL
at a minimum are going to look at Oracle for the same reason that
shops which at a minimum need the capabilities of MySQL would be smart
to look at PostgreSQL: their needs may grow over time and changing the
database mid-project is difficult and time-consuming.  The difference
is that the prices of MySQL and PostgreSQL are the same, while the
prices of PostgreSQL and Oracle are vastly different.

That's not to say that going after the Oracle market shouldn't be done
(quite the opposite, provided it's done honestly), only that *not*
going after the MySQL market is folly.


-- 
Kevin Brown					      kevin@sysexperts.com

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

cbbrowne@cbbrowne.com wrote:
> Kevin Brown wrote:
> > Simply saying "MySQL has better marketing" isn't enough.  It's too
> > simple an answer and obscures some issues that should probably be
> > addressed.
> 
> I think it /is/ a significant factor, the point being that the MySQL company 
> has been quite activist in pressing MySQL as "the answer," to the point to 
> which there's a development strategy called "LAMP" (Linux + Apache + MySQL + 
> (Perl|Python|PHP)).

Oh, I'll certainly not dispute that marketing has had a significant
effect, but I don't think it's the only reason for MySQL's success.

History has a lot to do with it, because it's through history that
momentum gets built up, as it has with MySQL.

> > People use MySQL because it's very easy to set up, relatively easy to
> > maintain (when something doesn't go wrong, that is), is very well
> > documented and supported, and is initially adequate for the task they
> > have in mind (that the task may change significantly such that MySQL
> > is no longer adequate is something only those with experience will
> > consider).
> 
> ... And the consistent marketing pressure that in essence claims:
> 
>  - It's easier to use than any alternative;
>  - It's much faster than any other DBMS;
>  - It's plenty powerful and robust enough.
> 
> As near as I can tell, /none/ of these things are true outside of very 
> carefully selected application domains.  But the claims have been presented 
> enough times that people actually believe them to be true.

I agree with you -- now.  But the situation as it is now has not
always been.  Consider where PostgreSQL was 4 years ago.  I believe it
was at version 6 at that time, if I remember correctly.  And as I
recall, many people had very significant issues with it in the key
areas of performance and reliability.  Now, I didn't experience these
things firsthand because I wasn't using it at the time, but it is the
general impression I got when reading the accounts of people who
*were* using it.

MySQL at the time wasn't necessarily any more reliable, but it had one
thing going for it that PostgreSQL didn't: myisamchk.  Even if the
database crashed, you stood a very good chance of being able to
recover your data without having to restore from backups.  PostgreSQL
didn't have this at all: either you had to be a guru with the
PostgreSQL database format or you had to restore from backups.  That
meant that *in practice* MySQL was easier to maintain, even it crashed
more often as PostgreSQL, because the amount of administrative effort
to deal with a MySQL crash was so much less.

> > PostgreSQL has come a long way and, with the exception of a few minor
> > things (the need to VACUUM, for instance.  The current version makes
> > the VACUUM requirement almost a non-issue as regards performance and
> > availability, but it really should be something that the database
> > takes care of itself), is equivalent to MySQL in the above things
> > except for documentation and support.
> 
> I would point to a third thing: Tools to support "hands-off
> administration."  My web hosting provider has a set of tools to let
> me administer various aspects of my site complete with "pretty GUI"
> that covers:
>
>  - Configuring email accounts, including mailing lists, Spam
>    Assassin, and such;
>  - Configuring subdomains;
>  - Managing files/directories, doing backups;
>  - Apache configuration;
>  - Cron jobs;
>  - A couple of "shopping cart" systems;
>  - A "chat room system;"
>  - Last, but certainly not least, the ability to manage MySQL
>    databases.
> 
> There is no "canned" equivalent for PostgreSQL, which means that
> ISPs that don't have people with DBMS expertise will be inclined to
> prefer MySQL.  It's a better choice for them.

This is true, but the only way to combat that is to get PostgreSQL
more widely deployed.  Network effects such as that are common in the
computing world, so it doesn't come as much surprise that the most
popular database engine in the webhosting world is the best supported
one for that role.

It's only because of the relative popularity of MySQL that it has so
much support.  The only way to grow PostgreSQL's popularity is to get
it deployed in situations where the tools available for it are
sufficient.

> > But you're mistaken if you believe that MySQL isn't competition for
> > PostgreSQL.  It is, because it serves the same purpose: a means of
> > storing information in an easily retrievable way.
> 
> Indeed.  People with modest data storage requirements that came in
> with /no/ comprehension of what a "relational" database is may find
> the limited functionality of MySQL perfectly reasonable for their
> purposes.

This is true, but the biggest problem is that the requirements of a
project often balloon over time, and the demands on the database
backend will also tend to increase.  Because MySQL is rather limited
in its functionality, it doesn't take much until you'll be forced to
use a different database backend.

This is why I view PostgreSQL as a much wiser choice in almost all
cases where you need a database engine.  Your needs will have to be
quite considerable before PostgreSQL's capabilities are no longer
enough.

> PostgreSQL has enough decent constructs, what with mature
> implementations of foreign keys, views, and constraints that it is
> fairly easy to build relational systems using PostgreSQL.  In
> contrast, the paucity of supportive constructs in MySQL means that
> neither the database nor the resulting applications are likely to be
> terribly "relational" in the senses intended by Codd and Date.

This is true, but what everyone fails to ask is whether or not any
particular customer really *cares* about that.  The customer isn't
interested in whether or not an application is "relational", they care
whether or not the application does the job it's supposed to.  How
"relational" it is is an implementation detail to them.

The reason that PostgreSQL wins over MySQL is not so much that it's
easier to build relational systems with it, but that it's easier to
build *reliable* systems with it.  That building the system in a
relational way is one way to achieve that is, again, an implementation
detail.

> > Selling potential MySQL users on PostgreSQL should be easier than
> > doing the same for Oracle users because potential MySQL users have at
> > least already decided that a free database is worthy of consideration.
> > As their needs grow beyond what MySQL offers, they'll look for a more
> > capable database engine.  It's a target market that we'd be idiots to
> > ignore, and we do so at our peril (the more people out there using
> > MySQL, the fewer there are using PostgreSQL).
> 
> The unfortunate part is that those that outgrow MySQL are likely to
> have /two/ misconceptions:
> 
> 1.  That the only /real/ reliability improvement will come in moving to 
> something like Oracle;
>
> 2.  That PostgreSQL will be a huge step backwards into performance problems 
> because it is "so much slower."

This is because people lack familiarity with PostgreSQL.  That's where
marketing PostgreSQL well comes in.

The performance misconception is the result of history.  At one time
PostgreSQL *was* much slower than MySQL.  People need to be informed
of the current state of affairs.

> That these are misconceptions does not prevent people from believing them.  
> (The third deceptive misconception I see is that MySQL is somehow "more 
> standard" than some of its competitors.)

The third misconception happens because most people equate "standard"
with "popular".  And in the real world, they're not entirely wrong to
do so, unfortunately.

> I think it would be a Bad Thing if making PostgreSQL support Windows
> better were to compromise how well it works on Unix, but I haven't
> seen evidence of anyone actually proposing patches that would have
> that result.

I agree, and I also believe that the maintainers would not accept a
patch that compromised the performance under Unix for the sake of
supporting Windows.  And rightly so: such a patch would indicate that
the people doing the Windows port haven't solved the problem properly.

> You can't sell into the "ISP appliance market" until there's
> something as ubiquitous as "PHPMyAdmin" for PostgreSQL.

But there is: PHPPgAdmin (or whatever it's called these days.  I seem
to remember that they changed the name of it).  Unfortunately it's not
as well known, largely because PostgreSQL itself isn't as well known.

> And note that the "ISP appliance market" only cares about this in a
> very indirect way.  They don't actually use the database; their
> /customers/ do.  And their customers are likely to be fairly
> unsophisticated souls who will use whatever database is given to
> them.

And if that's *really* true, then providers will do just as well to
provide PostgreSQL as they would MySQL (since their customers will
just use whatever database they're given).  So it's really a question
of selling the providers on it, which (as you mentioned earlier) is in
part a matter of giving them the tools they need to make managing a
PostgreSQL installation easy.

> There are Oracle markets /not/ worth going after, at this point.
> You /don't/ go after the "ERP" markets or the data center markets
> where license budgets are in millions of dollars, and where it's
> going to be tough to take PostgreSQL seriously when Oracle is
> entirely prepared to send in a group of 10 technical marketing
> people to swamp the customer with marketing information.

This is why marketing PostgreSQL *honestly* is so important.  If it
won't do the ERP job well, then it behooves those who are promoting it
to realize that and restrain themselves appropriately.

> What /is/ worth going after is the "small server" market, for
> departmental applications.  It's not "big bucks;" in the Oracle
> realm, it might lead to a licensing fee of $20K.  For $20K, they
> aren't going to send in a swarm of marketers to fight for the
> account.

And this is exactly one of the markets that MySQL is currently
targeting.  Of course, MS-SQL is *also* targeting this market, with a
reasonable amount of success.  PostgreSQL is a *perfect* fit for this
kind of operation, and it's one of the reasons that it really *is*
important to have a native Windows port.

> > That's not to say that going after the Oracle market shouldn't be done
> > (quite the opposite, provided it's done honestly), only that *not*
> > going after the MySQL market is folly.
> 
> Indeed.
> 
> It is almost a "necessary defense" to counter the deceptive claims
> that are made.  If nobody says anything, people may actually
> /believe/ that PostgreSQL is vastly slower.

The way you counter such deceptive claims is to provide proof that
those claims are wrong.  Point them at the head-to-head comparison on
the PHPBuilder site.  Prove to them that PostgreSQL is in the same
league (if not better) as MySQL in the performance arena.  And for
deity's sake, show them how much *less* work they'd have to do under
PostgreSQL because of its referential integrity features.  I really
think most people would be willing to sacrifice a small bit of speed
if it meant doing a whole lot less work.


Copied to the advocacy group because of the relevance.


-- 
Kevin Brown					      kevin@sysexperts.com

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Marc G. Fournier wrote:

> So as to not recreate the wheel, or, at least, get the wheel properly
> rolling, can we get that download page redirected to the one that does
> list the mirrors? :)

Yep.

Would the best way to do this be changing the wording to say something like:

"PostgreSQL can be downloaded as source code from any of the many mirror 
sites:"

With a link after it directing to somewhere that gives the list.  The 
present "www.postgresql.org" with the list of mirrors would probably be 
adequate, but it'll need to be a different url than the straight 
"www.postgresql.org" as that's going to change as soon as the new portal 
is in place.

Does this sound like a workable approach for now?

Regards and best wishes,

Justin Clift


> I liked Greg(?)'s ideas, but I don't see it as being implemented overnight
> :)
> 
> 


-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group Announces

Re: [GENERAL] PostgreSQL Global Development Group

Re: [GENERAL] PostgreSQL Global Development Group Announces