>Hi Sergey,
>
>using integer indices seems to get the biggest boot when using .idx. Also updating fields which are used as an index is markedly different in my tests - and this goes for all field types. The update cost can be seen in appending/inserting as well.
>
>cdx seem to catch up as tables grow larger, and seem to be better if used in SQL queries. I do realize that the test for SQL select is bordering on insanity, since different tables are used for one and also fill dynamically the where clause - only because the results were surprisingly stable I left that one in. With larger tables the number of queries rises and should even out sampling effects.
>
>Since the other results showed clear trends in repeated runs and across different table sizes / machine[s] configs / index target disks I am not too worried that I am comparing the "work" done on completely different tables during measurement. Law of large numbers is nice here...
>
>The code is meant to be tweaked for "personal stiuation" - the areas to tweak should be evident. I had thought the differences were smaller, but this probably stems from tests done way back in FPW without an integer PK... Not really usable for "my" UC still in vfp8 and using char PK's, but interesting nevertheless. And I will keep it in mind if I run into slow running reports. Definitely worth considering if you are constantly hitting small tables with integer PK's or always have to update indexed fields.
>
>Thanks to Fabio for making me look again at the numbers.
>
>regards
>
Thomas,

How long is your test? I killed it after 15 minutes because there was no indication if it was doing anything.