Um, OK, allow me to put you right - or rather, correct my screw up.
Interbase GENERALLY will get it right (assuming you have an index on that
column),
but sometimes (1-2%) it doesn't. Try it without the PLAN stuff first - 'cos
if you go up to IB6, the
planning has been rewritten and (I'm told) it works real well now. Dunno why
or how tho.
That said, tuning your SQL is a good thing. An example, which no doubt Kerry
will
correct me on ('cos its his 'problem') goes something like: joins (where
joins) are
evaluated in REVERSE order. So put the one that will resuce the result set
the most LAST, NOT
first!
I think that was it - K-man, if your out there, can you post that little bit
of code from your
FT-search thing? I can't remember the exact query.
N
--
Nic Wise - 021.676.418 / [EMAIL PROTECTED] / Inprise/Borland New Zealand
Is it not a foolish man, said little Woo, who keeps all his chickens in his
trousers?
For at best, will he not suffocate his chickens, and, and worst, will he not
disappoint the ladies in the village? --Alexi Sayle
----- Original Message -----
From: "Nahum Wild" <[EMAIL PROTECTED]>
To: "Multiple recipients of list database" <[EMAIL PROTECTED]>
Sent: Wednesday, March 01, 2000 5:13 PM
Subject: RE: [DUG-DB]: Which is fastest
> I will check it out, thanks.
>
> -----Original Message-----
> From: Nic Wise [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 1 March 2000 14:57
> To: Multiple recipients of list database
> Subject: Re: [DUG-DB]: Which is fastest
>
>
> Basically, you write the plan for IB. After looking at it a little closer,
I
> dunno if I'd recommend it, unless its getting wrong all the time. Using
the
> wISQL tool you can see what the plan is. I dont know either your data, or
> writing plans well enough to just write one.
>
> Try there where clause bit first - maybe abstracting each 'type' into a
view
> would make sure the corrent index was being used?? (assuming it was going
to
> get it wrong)
>
> N
> --
> Nic Wise - 021.676.418 / [EMAIL PROTECTED] / Inprise/Borland New Zealand
> Is it not a foolish man, said little Woo, who keeps all his chickens in
his
> trousers?
> For at best, will he not suffocate his chickens, and, and worst, will he
not
> disappoint the ladies in the village? --Alexi Sayle
>
>
>
> ----- Original Message -----
> From: "Nahum Wild" <[EMAIL PROTECTED]>
> To: "Multiple recipients of list database" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 01, 2000 2:33 PM
> Subject: RE: [DUG-DB]: Which is fastest
>
>
> > How would I go about forcing Interbase to use the index first? Bearing
in
> > mind that I have not played with query plans yet.
> >
> >
> > Nahum
> >
> > -----Original Message-----
> > From: Nic Wise [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, 1 March 2000 13:59
> > To: Multiple recipients of list database
> > Subject: Re: [DUG-DB]: Which is fastest
> >
> >
> > If the column is indexed, it shouldn't make too much difference. Its the
> > difference between
> > altering your code (ouch) to hit other tables, and having the big table
> > go one level down in the B-Tree.
> >
> > I'd go with the single table, assuming you have it that way already, and
> > index to hell and back. Also, try and force Interbase to use that index
> > first - its not allways that bright when it comes to query planning :)
> >
> > N
> > --
> > Nic Wise - 021.676.418 / [EMAIL PROTECTED] / Inprise/Borland New
Zealand
> > Is it not a foolish man, said little Woo, who keeps all his chickens in
> his
> > trousers?
> > For at best, will he not suffocate his chickens, and, and worst, will he
> not
> > disappoint the ladies in the village? --Alexi Sayle
> >
> >
> >
> > ----- Original Message -----
> > From: "Nahum Wild" <[EMAIL PROTECTED]>
> > To: "Multiple recipients of list database" <[EMAIL PROTECTED]>
> > Sent: Wednesday, March 01, 2000 11:40 AM
> > Subject: [DUG-DB]: Which is fastest
> >
> >
> > > I'm currently designing a rework of a DB from a speed point of view,
we
> > are
> > > using Interbase. The bone of contention at the moment is that we have
a
> > > datalogging table where each unique key represents a system being
> > monitored.
> > > For each system/unique key there will be tens of thousands of records
> > giving
> > > hundreds of thousands, even millions, of records in total for the
table.
> > > Via the user interface the user only ever sees one systems data at any
> one
> > > time, so whenever I run a query over the table it must include a WHERE
> > > clause filtering out all records belonging to the other monitored
> systems.
> > >
> > > My question being from a speed point of view would it be quicker to
give
> > > each system its own table rather than lumping them all together. Thus
> > > removing the need for the WHERE clause meaning the query would be just
a
> > > straight dump of the data? Now obviously it would be quicker but how
> much
> > > quicker? and would it be noticable? I don't know much about
Interbase's
> > > inner workings and for all I know Interbase could effectivly be doing
it
> > > behind my back anyway.
> > >
> > >
> > > Thanks in advance...
> > >
> > >
> > >
> > > Nahum Wild
> > >
> > > Software developer type person
> > > Invensys Energy Systems (NZ) Limited.
> > > (formally Swichtec Power Systems)
> >
>
> --------------------------------------------------------------------------
> > -
> > > New Zealand Delphi Users group - Database List -
> [EMAIL PROTECTED]
> > > Website: http://www.delphi.org.nz
> > >
> >
>
> --------------------------------------------------------------------------
> -
> > New Zealand Delphi Users group - Database List -
[EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
>
> --------------------------------------------------------------------------
> -
> > New Zealand Delphi Users group - Database List -
[EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
> >
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
