On 29.10.2007, at 19:52, Mike Schrag wrote:
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?
As far as I understood Geert, this will not reclaim space on disk. You'll have to do a backup/restore cycle to get that back.
We had that problem with a fairly large logging database, where the space on disk doubled after an optimize - to 40GB ... And backup / restore takes too long to tolerate the downtime.
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.
Yes, same feelings here. I'd love to see something like "explain analyze ..." on FrontBase. The output in FrontBase only told me, that it was using some indexes for this and that, but that's about it.
Can't you just pg_dump your tables?
Sure you can, but than you have just one monolithic backup. And point in time recovery, what FrontBase backup does if you keep transaction logs, is on PG just plain pain in the ... wherever. FrontBase is easier to setup with that and just works (at least it did for us). PITR in PostgreSQL requires for a non-dba some serious shell scripting testing and digging until it works as expected. And even than it is "not nice".
For a dba, this might sound ridiculous, but for me it isn't.
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.
You can't do either with PostgreSQL PITR (basically wal archiving). We found, that it mainly works from a Linux 64 bit Suse box to a Mac OS X Server (Leopard), 64 Bit compiled PG, if you recreate all indexes on the Leopard machine or use a plain C locale.
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).
I do the same.
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.
Maybe this will appear one day if you ignore it long enough? Who knows? :-P
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.
We had the same problem about two years ago when I was still working in Germany, and it was really a pain. The planner did an obviously wrong choice (doing a nested loop or something similar over a set of more than 100k rows ...) where it could just use a subset (or subselect). The query was generated by D2W, so not much I could do about that without hacking way to deep and loosing all the "nice, fast and easy" development. I switched this app to PostgreSQL which handled that case way better.
As far as I know, FrontBase has solved this by bringing the query optimizer that was planned for version 5 into version 4. It solved the problem for the queries I had, but was still about a factor of two or three slower on that kind of stuff than FrontBase was. And we were on fairly old hardware and needed the speed. So we stayed with PG for that.
But to be fair: if you run into that kind of problem, the guys at FrontBase really want to help you and normally they find a way quickly.
cug _______________________________________________ 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]
