At 01:14 AM 5/25/02 +1000, Helen Borrie wrote:

>At 10:28 AM 24-05-02 -0400, Jim Starkey wrote:
>
>>Finding the problem should be extremely simple. Take a relatively
>>simple case of optimizer screw-up and find why it screwed-up.
>>Until version 4, it worked like a charm. Hint: problem is likely
>>to be in the area where it considers index walking rather than
>>scanning.
>
>What's the difference between walking and scanning?
>

One of the signatures of designed-by-Jim databases is that
index retrievals of performed by first scanning the index
setting bits is a sparse bit from record numbers, then
processing records in bit order. Non-Jim databases walk
the index bouncing between index nodes and the actual
records.

Scanning is always a big win from a performance perspective
for a number of reasons, but index walking gets to the first
record most quickly. If you lied in your query and only
intended to get the first couple of records, record walking
can be faster (solution: Don't lie!).

I put in index walking for DBase-IV emulation, but was triggered
by presence of the blr first and sort clauses. I believe somebody
decided they could win some benchmarks at the expense of throughput
by using walking rather than scanning, but hacked it in rather
than doing a proper architectural extension.

DBase-IV emulation was a very important feature for Interbase
Software Corporation-I, but isn't worth diddly squat now. Special
hacks to win benchmarks that in fact slow the system down are
always, always a mistake (winning by an unsustainable cheat
is a business loss).

Firebird would be a better product is the index walking were
either ripped out in entirety or eliminated from the optimizer
in the absence of unmistakable markers.

Jim Starkey