On 09.01.2008, at 13:51, Martin wrote:
I've been working with FrontBase a lot lately and I wouldn't say
anything about it qualifies as "incredibly easy" and reliable it
is not.
We had never ever any reliability issues with FrontBase as long as
didn't try to insert garbage. It really doesn't like that.
Performance of FrontBase is just plain terrible. One of
our reports takes 9 minutes on FrontBase and 10 seconds on
Postgres.
As I said: depends on what you are doing.
Which version did you use where you got that terrible performance? The
latest one? There was a bug in there query planner in an old version
that totally killed some queries.
There is also the or-query problem (not sure whether that one is still
in there): if your report does something like "select bar from foo
where a = 1 or b = 1;" it didn't use indexes on a or b which is
terrible. If you have that, use separate selects combined with a union
if you can.
In my cases it was never as fast as PostgreSQL as soon as there are
more than two tables involved. But except a couple of cases where I
had to use PostgreSQL for performance reasons, I was okay with it. But
performance is not everything.
PostgreSQL is for most cases the better product, but for some cases,
FrontBase is. Depends on what you're doing how much which side has ...
Then there's the documentation issue...
PostgreSQL documentation is better, but what is your issue exactly?
The main problem I have with the FrontBase documentation is that it
mostly gives no useful examples.
As this is off-topic here: we can transfer that either to the
FrontBase list or to private mail if you like.
cug
--
http://www.event-s.net
---------------------------(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
