On Jan 5, 2007, at 14:39, Vlad Horsun wrote:

>> Incidentally, I apologise if this came across as overly negative.
>> Generally speaking, we are very happy with Firebird as an embedded
>> engine. Part of my job, however, is to be (sometimes painfully!)
>> aware of the subtle differences between 9+ different SQL engines. So
>> when I am doing comparisons like this, every little wart is magnified
>> because I know how several other engines do the same thing "better".
>
> Understand. But i'm pretty sure there are opposite cases
> where Firebird is "better" :)

OK then!

- The only thing I have looked at that has a smaller footprint than
FB is SQLite - which has no date types
- Deployment is a breeze
- Joins using "IS NOT DISTINCT FROM" are much easier to express -
and I bet they use indexing well. Nothing else has this that I know
of (well, besides the standard...)
- Column level collation (Jet, Oracle(!) and Postgres are cluster
level only)
- Domains. Made it possible to define a boolean type. Not a
common capability.
- File based. Makes it easy to move data around.
- The documentation is MUCH better than Jet's
- Data integrity is much better than MySQL (I know, so is
everybody's...)
- Nicely normalised metadata tables. Just try to find all the
foreign key references with MySQL 4...
- Count Distinct. Unlike Jet.
- Better sub-second time support than SQL Server (and MySQL and Jet)
- Database size essentially unlimited (unlike Oracle XP, SQL Server
XP, Jet)

Also, bear in mind that my needs are exclusively OLAP, so there may
be other fine points of FB that I don't run into on a daily basis ; -)

>> That does not mean that FB is "horrible" by any means, but I do think
>> it is good to point these things out - especially in a thread that
>> started out comparing FB to PG.
>
> Of course. But your picture with test results useless without
> description
> of the tests itself. Or am i missed something ?

I think it is a pretty fair apples-to-apples comparison of Postgres
and Firebird using out of the box installs running the same set of 850
+ OLAP queries on the same machine over a period of time long enough
to get things into a stable state. The queries themselves are used
to generate data visualisations from small-to-mid-sized data sets (O
(50K) rows). The thing that I would point out to the FB crew is that
I have done extensive tuning of the FB data sets (page size,
indexing, etc.) and almost nothing for PG (not even indexing), yet PG
consistently runs in 2/3 the time. This is worth knowing.

Happy Perihelion everyone!
________________________________________________________
Richard Wesley Senior Software Developer Tableau
Software
Visit: http://www.trytableau.com/now.html