Yes, we are still trying to go faster and are wondering how important

the speed of a dedicated indexing workstation is in the performance of

other workstations. If an non-indexing workstation makes a call to

an index does it require the indexing workstation to process that

index at that time? I've noticed that if the indexing workstation is

turned off, that a non-indexing workstation processes index updates

when a call is made. Will an indexing workstation that is faster

lessen the amount of work the other workstations have to do, thereby

making their performance faster? TIA, Jim

Yes. Faster is always better. More is also better. For example, we have our files spread across 4 directories - 3 of which are served by a dedicated indexer and 1 of which is composed of files that are not to be indexed.

Faster also comes closer to avoiding users searching on indexes that are not updated

Our searches run faster when no fields are selected.

We also found that we get less GFE's when we told everyone to stop turning on their machines.

I have to add that the solving the GFE benifit came by accident. The original purpose of leaving the machines off was to prevent the Good Times virus from affecting our systems.

Gary Gnu

Yes, we are still trying to go faster and are wondering how important the speed of a dedicated indexing workstation is in the performance of other workstations. If an non-indexing workstation makes a call to an index does it require the indexing workstation to process that index at that time? I've noticed that if the indexing workstation is turned off, that a non-indexing workstation processes index updates when a call is made. Will an indexing workstation that is faster lessen the amount of work the other workstations have to do, thereby making their performance faster? TIA, Jim

It depends what the other workstations are doing. If the other workstations are just updating records (thus creating new index transactions), the performance difference will be negligible. This is because of the way pending indexes are stored. When a record is updated, a token indicating what index should be processed by the indexer is saved to the index file. If there are many pending indexes, the first record of pending indexes points to the end of the daisy chain, and the write process goes straight to the end. There are a couple things that can still slow this process down:

* If the index file had a sizelock of 2 or greater, causing excessive overflow to be used.

* Another workstation does a rebuild of an index. Updating will be suspended until the rebuild is complete.

If, on the other hand, workstations will be doing searches based on the index, there will be a performance hit if your environment is configured to update indexes before selects. In this case, all pending indexes for the indexed field being used will be flushed prior to execution of the select statement. This has two affects on performance:

1) The workstation performing the select must wait until the update completes.

2) Since the update flushes only updates for the field being selected, index information for other fields remains unflushed. This results in excess baggage that must be waded through every time a select is performed.

Wow. I could solve lots of my own problems by telling the users to not turn on their machines.

Wow. I could solve lots of my own problems by telling the users to not turn on their machines.

Just kidding…

Just kidding….

I had lots of problems with my old Intel chips. Actually I had 288 of them. I'd tell you but it's too gross. Could have been my problem. Maybe I should have used a 286 chip instead of a potato chip. Serves me right for buying a green machine. Now I have these nightmares of Ian Paisley screaming "The future's bright! The future's orange!" I'm a iguana, not a chameleon! A leopard can't change her spots, you know.

Ilona Iguana

View this thread on the forum...