+ has "vacuum full", to shrink the footprint of the db on disk
in FB, you might want to take a look at:
OPTIMIZE DATABASE;
OPTIMIZE DISK ZONE <disk zone name> | DEFAULT;
(see Page 115 of the FB User Guide for more info) ... Maybe will help?
+ query planner analysis tools ("explain analyze select ...")
Yes! FB has a query plan output also, but it's worthless. It's
totally cryptic and doesn't nearly report enough information about
what it did. My kingdom for them to make this better and on par with
most of the competition.
+ backup (backup sucks with PostgreSQL and is amazingly easy with
FrontBase)
Can't you just pg_dump your tables? Or is that not transaction safe?
And just for completeness, I always have strange problems with FB
Backup/Restore -- For one, they're not endian-safe, so you can't
backup and restore across architectures, which just sucks. For
another, it seems to segfault under odd circumstances for me when I
try to move across machines, even of the same architecture. I write
backup and also write all output just to be safe (write all output is
actually not transactionally safe on FB, but I like to have it as a
"just in case" in the event of an emergency). The other thing is that
they can't just give me a damn SQL dump. It's always in some goofy
format whether you "write all output" or "write backup". I'm not sure
why they don't offer this route when everyone else does. It makes
migrating across databases substantially more complicated, which is
maybe why they do it, who knows.
+ fulltext indexing (LookSee)
Another wish I have is if I add a fulltext index, that I could tell it
to make '%whatever%' queries use LookSee so I don't have to resort to
proprietary SQL to do it. I know WHY they don't do this, but it would
just be a little nicer. I always mean to write a FullTextQualifier in
Wonder that will turn into the proper SQL for a full-text search in
the various databases, but I never seem get around to it.
So, it depends on what you need. If you want a database server, that
runs out of the box with nearly perfect backup and clustering
support - get FrontBase. If you need to tweak a LOT of things to get
the best performance out of a large and complex database - I'd use
PostgreSQL.
Yeah I would agree with this, too ... And we mix and match. The other
one is that PG has a much better query optimizer. If you ever do a
left outer join in FB, you may find that under certain circumstances
performance really sucks. We had to switch one of our apps over to PG
which handed FB its ass in query performance with a complex query over
a fairly large dataset. For straight WO, this turns out to not matter
much, because WO tends to generate fairly simple queries, but if you
ever have particular complex custom SQL fetches, you might run into it.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
