Re: Are we losing momentum?

>From my experience, almost every time I talk to a MySQL supporter about
PostgreSQL, the whole "vacuum" issue always seems to come up. Some way
to get vacuum automated (and thus out of sight, out of mind) I think
would make great strides in making PG at least "seem" more friendly to
someone on the outside.

Shared hosting enviroments. I work for a web hosting company that offers
MySQL to all of its customers, our MySQL server has several thousand
databases on it, and I must say it works exceptionally well.

Creating users/databases/changing passwords is as simple as sending it a
couple queries from our Customer web interface, trouble shooting poor
queries takes seconds when using "mytop" (mtop), and tracking/billing
for disk usage is as simple as running "du /var/lib/mysql/*". I would
like to say the same things for PG, but I'm affrid I can't.

I think it all comes down to how simple PG is to setup and use on a
daily basis. This is what determines the size of its community. Even
just the simple things make a big difference. ie:

\dt

compared to:

show tables;

Yes, once you get over the "hump" PG is quite efficient, but you need to
understand it, and learn some small quriks first. With MySQL, you can
pretty much guess commands, and they often work! Not as much luck with
PG.

show indexes
show processlist
show columns from <table>

These are all easy/simple commands that make sense to someone who is
just learning the ropes. Short abbreviated, commands are great for the
experts, but can greatly discourage newbies.

On Mon, 2003-04-14 at 18:52, Brent Verner wrote:
> Gretings!
>
> [2003-04-14 19:54] Tom Lane said:
> | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> | > Several people have asked if we are losing momentum.
>
> | I don't know what we can do about it, other than maybe push harder to
> | get some more PG titles into O'Reilly's catalog ... that would help
> | narrow the bookshelf gap a little, at least. Any wannabee authors
> | out there? (And Bruce, your book is due for a second edition...)
>
> I've wanted to pipe up in a few of these "popularity"
> discussions in the past. Seeing how I can't make time to
> participate in any other meaningful capacity, I'll share
> my thoughts on _why_ mysql has the mindshare.
>
>
> Applications, specifically applications that _use_ mysql.
>
>
> A quick search over at freshmeat returns 1044 results for
> "mysql" and 260 for "postgresql". Before this turns into a
> cause/effect discussion, I want to state up front that the
> real "effect" of this is that someone is 4 times as likely to
> download an application that uses mysql. Sure, many are
> "trivial" applications, but I posit that it is _specifically_
> these "trivial" applications that inoculate the uninitiated
> with the belief that mysql is suitable for use in real, albeit
> trivial applications. Additionally, it these rudimentary
> applications that will be studied by many as the way to write
> a database application.
>
> It is all good and well that postgres /can/ do, but until
> the application developers see that those features are
> valuable enough to forgo mysql support, they'll write the
> application to support whatever database is most likely to
> _already_ be installed, which will be mysql. Granted,
> many developers will also try to support multiple dbs via
> the language's db api, but this leaves the less-supported
> dbs in an even worse position; being relegated to an
> "might work with XXX database". When anxious user learns
> that "might" currently means "doesn't," the second-string
> database looks even worse in the eyes of the user.
>
> How to solve this problem? This is the hard part, but
> luckily ISTM that there are a few ways to succeed. Neither
> of which involves marketing or writing books.
>
> 1) become active in the "also supports postgres" projects,
> and add features that are made available _because_ of
> postgres' superiority. Eventually, market pressure
> for the cool feature(s) will lead users to choose
> postgres, and mysql could be relegated to the "also
> runs on mysql, with limited featureset"
> 2) take a popular project that uses mysql, fork it, and
> add features that can only be implemented using posgres.
> 3) release that super-cool code that you've been hacking
> on for years, especially if it is a "trivial" app.
> 4) convince your employer that it would be _beneficial_ to
> them to release, as open source, the internal app(s) you've
> developed, using postgres-specific features. (This is
> about all I can claim to be doing at this point in my
> indentured servitude, and I can't say I'm doing a good
> job... :-/)
>
> I'm sure this idea is not original, but I'm also sure that
> it _is_ the answer to gaining market^Wmindshare in this
> database market.
>
> (I must apologize in advance, that I might not have time
> to even follow this thread, in fact, I hope that instead of
> replying to this, the potential respondent might consider
> helping to increase the number of apps that require postgres
> :-)
>
> wishing-I-could-contribute-more-ly yours,
> brent
--
Best Regards,

Mike Benoit
NetNation Communications Inc.
Systems Engineer
Tel: 604-684-6892 or 888-983-6600
---------------------------------------

Disclaimer: Opinions expressed here are my own and not
necessarily those of my employer