buppcpp wrote:

> I've always saw performance as a reason to hold up a build for a while.
> Performance isn't a feature, it's a necessity. Look at MySQL for
> example. Lacks many features, but kills in performance and is the #1
> open source database because of it.
>
> Examples of broken items:
> 1. INSERT INTO TABLEA SELECT FROM TABLEA;
> 2. DELETE FROM TABLEA WHERE (SELECT FROM TABLEA);
> 3. Data type coercion of views in 1.5.2.(You have to cast too much.)
> 4. Data type coercion in general.(You have to cast too much.)
> 5. READ_COMMITTED Transactions.(still unclear on what should be used
> instead of...)
> 6. 20x slower page loading than PG.
> 7. There may be others that I missed or don't know about.

FWIW, I'm not saying that these things shouldn't be given priority or
that the FB project is being planed in an optimal way in these respects.
I just pointed out that asking for this-and-that to be implemented in
1.5 or 2.0 is almost for certain futile. Also, please note that I'm not
in the FB team at all - I'm just a rather novice FB user.

I agree that FB suffers from IMO serious performance problems in some
situations because of what seems to me a somewhat lacking set of tools
for the query optimizer to choose from, e.g. no hash sort/lookup. It
also seems to have problems finding the best plan with the *existing*
set of tools, in some situations, mostly in conjunction with indices
with low selectivity.

I've said it before and I'm going to say it again: Even if FB can be
shown to provide very good average performance in applications with many
concurrent read and write transactions if the application is well
written, it has performance problems in just a little too many other
situations to be very attractive to the average non-db-expert
application author.

I'd like to show a graph here, but I have this image of a graph where
different kinds of queries on the x axis and the db enginge's
performance on the y axis. I imagine that SQL Server, MySQL, PostgreSQL
etc have a fairly even curve, where performance is pretty good for all
kinds of queries. FB on the other hand, might have better performance in
many cases, but then it has some very big spikes where performance
really really sucks.

If you're an application author faced with the task of choosing a db
engine for a new application, not really knowing exactly what kind of
queries you will need to use, which db engine would you choose? I would
probably shun FB if I saw those graphs.

In other words, from a "marketing" perspective, I see nothing as more
important for FB than cutting those spikes, even if there are very
adequate workarounds for almost all of them.

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64