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
|
Список | 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 по дате отправления: