Re: [HACKERS] Enticing interns to PostgreSQL - Mailing list pgsql-advocacy

From Jeff Davis
Subject Re: [HACKERS] Enticing interns to PostgreSQL
Date
Msg-id 42E6A1A4.1060308@empires.org
Whole thread Raw
In response to Re: [HACKERS] Enticing interns to PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: [HACKERS] Enticing interns to PostgreSQL
List pgsql-advocacy
Jim C. Nasby wrote:

> So, how can we increase awareness amongst people who have yet to choose
> an OSS database? Awareness that PostgreSQL exists, and awareness that
> it's almost always a superior choice than MySQL.
>

There's actually pretty good awareness that PostgreSQL exists. However,
we aren't going to win the battle before people try PostgreSQL. The main
battles are getting important tools to use PostgreSQL, and getting
people to just try it out.

I think most people are very quickly impressed by PostgreSQL because it
is so consistant and you can almost feel the data integrity. Every
feature of PostgreSQL is part of a grand-unified, general solution. Good
examples would be extensible procedural languages, user-defined
functions, user defined types, GiST, etc. And to see how useful all of
those things are, you need to look no further than the likes of tsearch2.

The hardest part of getting a user to stay with PostgreSQL is taking
them from "OSS databases are MySQL and PostgreSQL in that order" to
getting their first helpful reply from the lists. I think that's the
place we really win them over, because they come in looking for a
checklist feature or a problem. Often they don't understand the
"feature" or they expect to stump the lists with their problem. Then
someone steps up and explains to them the right way to do it, why it's
the right way, and why PostgreSQL is the best database. And the reason
that wins them over is because usually they walk away thinking "wow,
that makes a lot more sense".

One thing that used to come up all the time on the lists was "PostgreSQL
won't use my index, how can I force it to?". Sometimes this resulted in
some fine tuning of the postgresql.conf, or even enable_seqscan=false.
However, many times it resulted in explaining that the planner concluded
that seqscan was faster, followed by an explanation of why the planner
thought so, followed by a demonstration that the seqscan was faster.

Imagine if you're a MySQL user, and you get an answer to a question like
that. You'd stick with PostgreSQL from that point on. That happened to
me 5 years ago (probably with a different question, it was a while ago,
but the point is the lists quickly set me straight :), and it certainly
worked, even though that was before 7.0 came out, and MySQL was more usable.

Regards,
    Jeff Davis

pgsql-advocacy by date:

Previous
From: Chris Travers
Date:
Subject: Re: ENUM type
Next
From: "Denis Lussier"
Date:
Subject: SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility