> Adam: I did download FlameRobin, its kind of a pain since it seems

hard coded to

> 100K records at a time and I didn't see a setting to increase that

anywhere, I

> could have missed it.

I don't know sorry. I usually don't bother with more than a couple of
thousand. Even with 10000 records you can usually know how well the
query will scale.

>
> Anyway, I put 1,000,000 records in the table and tested the

following SQL:

>
> SELECT
> s.oid
> ,s.sale_number
> ,s.pos_sale_number
> ,s.sale_type
> ,s.sale_state
> FROM
> SALE s
> WHERE
> s.USER_OID = '3-5555'
> AND
> s.SYSTEM_DATE = '6/19/2008'
> ORDER BY
> s.SALE_NUMBER;
>
> With the following results:
>
> PLAN (S ORDER IDX_SALE_SALENUMBER INDEX (IDX_SALE_USER_OID))
>
>
> Executing...
> Done.
> 1887 fetches, 0 marks, 0 reads, 0 writes.
> 0 inserts, 0 updates, 0 deletes, 26 index, 0 seq.
> Delta memory: 924 bytes.
> Execute time: 00:00:00.
>
> 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