Re: optimization/indexing
Re: optimization/indexing
- Subject: Re: optimization/indexing
- From: Chuck Hill <email@hidden>
- Date: Fri, 19 Dec 2008 07:03:57 -0800
On Dec 19, 2008, at 6:26 AM, Jeff Schmitz wrote:
Whoops, I think I misread the suggestion.
No, there wasn't an index for WinAnalysis.comboTeamID. And creating
one makes a HUGE HUGE HUGE (enough emphasis??) difference. from
minutes to less than a second to load the page. So it was the
'indexes' after all.
Again, many thanks, I should have a good nights sleep tonight :-)
There is a lesson in there: a little indexing goes a long way. I
suspect that some structural changes to how you have modeled this
might also make a further small improvement, but at less than a second
there is not the scope for this sort of improvement again.
EOF only generates the indexes for the PK and FK constraints. It is
up to you to know how you will query the data and add appropriate
optimization indexes. These can easily be the difference between an
app that flies and one that is unusable.
Chuck
On Dec 19, 2008, at 8:05 AM, Jeff Schmitz wrote:
OK, I tried to do this, and in the process hit a dialogue that said
I had to change my transaction settings to be serializable,
pessimistic, read write. Are these setting just for the FrontBase
Manager app, or global (i.e. also for my webobjects app?).
Anyway, after saying ok, change my transactions settings, I then
got an error that "Only explicit indeces can be dropped". So, I
was unable to drop my index and re-build it.
btw, why does the Mail app say 'indeces' is misspelled? Guess
we're supposed to stick to the more pedestrian 'indexes'. And they
call Mac users elitist ;-)
Jeff
On Dec 18, 2008, at 10:45 PM, Chuck Hill wrote:
On Dec 18, 2008, at 8:40 PM, Jeff Schmitz wrote:
Does WinAnalysis.comboTeamID have an index? I'd guess that it
does and that the index is corrupt. Or that is one VERY large
table and there is no index. If you can get FrontBase to use an
IN instead of ORs that will also make it faster, but you have
some kind of hunka burning serious SQL problem happening there.
It does have an ID, but it's an "owns destination" relationship.
And it is pretty large.
And ID or an index? Look at that table in FrontBaseManager, check
the indexes. If there is one, drop it and recreate it. If there
is not one, add it. Did that help?
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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