Re: [HACKERS] Enticing interns to PostgreSQL

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: [HACKERS] Enticing interns to PostgreSQL
Дата
Msg-id 42E6A1A4.1060308@empires.org
обсуждение исходный текст
Ответ на Re: [HACKERS] Enticing interns to PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: [HACKERS] Enticing interns to PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Chris Travers
Дата:
Сообщение: Re: ENUM type
Следующее
От: "Denis Lussier"
Дата:
Сообщение: SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility