|Subject||Re: Small Subsets of data|
> Adam: I did download FlameRobin, its kind of a pain since it seemshard coded to
> 100K records at a time and I didn't see a setting to increase thatanywhere, 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
> SALE s
> s.USER_OID = '3-5555'
> s.SYSTEM_DATE = '6/19/2008'
> ORDER BY
> With the following results:
> PLAN (S ORDER IDX_SALE_SALENUMBER INDEX (IDX_SALE_USER_OID))
> 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
> records in the table so I'd say that was pretty damn fast. I testedin the
> application too, where I need to display the user's current salesfrom 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 itlooks like
> its safe to use one table like I had hoped to do.Great it worked out for you. You may want to also try without the
IDX_SALE_SALENUMBER index by changing the last line to.
Often an indexed sort is slower than an in memory sort.