Re: Database choices
Re: Database choices
- Subject: Re: Database choices
- From: Guido Neitzer <email@hidden>
- Date: Tue, 30 Oct 2007 10:08:15 -0600
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden