On 18 Oct 2005, at 16:57, Andrew Sullivan wrote:
On Tue, Oct 18, 2005 at 04:37:23PM +0100, Alex Stapleton wrote:
Release a cheaper / free alternative and people will use it because
they will have almost no reason not to. This means that cheaper and
as good as does have a place in the market even if it's not a
conventional solution. It just needs evidence and evangelism. The
current market should not be the principal target.
I agree with this; but I'm always concerned about something that's
_almost_ as good as the competition, but not quite there, being
pointed at as being "as good as" the competition. That way lies an
invitation to the point-and-laugh responses that MySQL's so-called
cluster system has garnered: it's too dangerous to use for many
systems where the data is important enough, because the failure mode
is "near-complete catastrophe". See another thread, where I talk
about the strategy some companies may be using of lumping PostgreSQL
in with other products, and then attacking the other product.
Irrelevance may be fallacious, but it makes for depressingly
successful marketing.
If MySQL advertised it's bad points as well as it's good points it
would not be nearly as dangerous, or generally laughable as a
database. For example MySQL Cluster (NDB) is actually not that bad in
a lot of cases, and can probably be pretty useful in a lot of
situations. Unfortunately it seems to get mistaken (possibly even
marketed as?) an actual database, rather than just a particularly
smart caching system.
A known quantity, is often infinitely better than a homegrown or
unknown solution (which most homegrown ones really are.) Even if it
is not as good as RAC.
I agree that any solution which has a failure mode of nearly complete
catastrophe is pretty much useless, but it's only dangerous (and an
industry joke) if marketed using FUD in the same way MySQL do. I
don't see any reason to worry about PostgreSQL getting bad (false)
press, there are plenty of big names using PG, and plenty of
commercial interest in it. It's not like PG should be aiming to
render Oracle and so on redundant, it's the wrong way of thinking
about it imo.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
