Adam wrote:

> > > > It returned like 18 records that matched the criteria from the
> > > 1million +
> > > > records in the table so I'd say that was pretty damn fast. I tested
> > > in the
> > > > application too, where I need to display the user's current sales
> > > from today and
> > > > it was very, very fast. Coupled with a nice little "Please Wait..."
> > > message
> > > > that displays for like .5 seconds for subjective speed and I say it
> > > looks like
> > > > its safe to use one table like I had hoped to do.
> > > >
> > > > Nice.
> > >
> > > Great it worked out for you. You may want to also try without the
> > > IDX_SALE_SALENUMBER index by changing the last line to.
> > >
> > > ORDER BY
> > > s.SALE_NUMBER+0;
> > >
> > > Often an indexed sort is slower than an in memory sort.
> > >
> > > Adam
> > >
> >
> > I'll try that. I'm using an OPF so I'll have to write a hard coded
> visitor in
> > the morning to do that. In the meantime, does the +0 negate the
> index somehow?
>
> Yes.
>
> s.SALE_NUMBER+0 is not an indexed expression, but obviously it is not
> going to effect the order. Firebird will not find a plan involving an
> ordered walk of the table. It will read the results in the order they
> are stored on disk, then sort them in memory.
>
> For 18 records, there is probably not much difference, but it takes
> longer for disk platters to jump around to random locations on disk
> than it does for arbitrarily ordered data in memory to be sorted.
>
> Adam
>

BTW, where can I study up on optimizations like this?

Thanks,

--
Warm Regards,

Lee