Does the dict item data type factor when indexes are build, rebuilt, update_index and also btree.extract.

Are certain data types more efficient than others. it seems I only use date, varchar or integer

For example does an index on data like "123456789012345" work better as a right just varchar or as an integer - or does it even matter

I would have to think a Boolean indexes faster AND btree.extract on a Boolean would be faster ?

Any low level advise ?

Maybe Aaron can check in and also let me know how is Flyers are going to do this year as well :)

Bri

I am ready to be proven wrong on any of this, but data typing was the purely for the old ODBC bond so that OI would know how to convert the data when asked for it for an external source. Beyond that, everything is a string ultimately.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

I am ready to be proven wrong on any of this, but data typing was the purely for the old ODBC bond so that OI would know how to convert the data when asked for it for an external source. Beyond that, everything is a string ultimately.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

I would have to think a Boolean indexes faster AND btree.extract on a Boolean would be faster ?

Are Bitmap Indexes still a thing? That should be faster for a boolean index.

Cheers, M@

Vernon Systems

OI treats indexed values as strings regardless of the dictionary data type.

OI does pay attention to the justification of the data - it uses slightly different methods to determine gt or lt in range searches.

In general, the fewer keys per indexes value an index, the more it will help you. A boolean index has only two values, so a btree.extract might return most of the keys in the table.

Bitmap indexes are still in the product, but, TBH, the way I implemented them added overhead which removed the speed benefits.

Bitmapped index rely on a list of 1/0's whose position depends on the key. For a sequential key the bit position equals the bit position. I added a layer to map alphanumeric keys to physical positions in a list. The correct solution is to remove the extra layer and restrict bitmapped indexes to tables with an integer key.

Tx Bob for the clarification.

I am also assuming btree.extract works (reduces) in a first to last order with multiple criteria ?

For example below CritA reduces first then CritB followed by CritC ?

CritA @FM CritB @FM CritC @FM

And in RList I assume it reduces all the WITH fields that are indexed first to last and then it applies all the WITHs that are not indexed?

tx

Bri

Does the dict item data type factor when indexes are build, rebuilt, update_index and also btree.extract.

Are certain data types more efficient than others. it seems I only use date, varchar or integer

For example does an index on data like "123456789012345" work better as a right just varchar or as an integer - or does it even matter

I would have to think a Boolean indexes faster AND btree.extract on a Boolean would be faster ?

Any low level advise ?

Maybe Aaron can check in and also let me know how is Flyers are going to do this year as well :)

Bri

Sorry, late to the party here.

Everyone's pretty much correct on this. Datatyping really only matters for some of the bonds. There's some other occasional uses where if there isn't an iconv/oconv value, it might use the datatype to try finding one, but I think that's only in the projex modules, and again, it's just for SQL stuff.

The things that make a difference are justification, length and MV value.

Justification will sort left or right, so alphabetic or numeric. That will make a difference on how 1, 2, 10, 20, 3, 300 are sorted Lenght is also a factor, since newer code (and by newer I mean ARev 3, so circa 1990 so the last 30 years) uses C or ASM to sort, so it wants fixed length pages.

Otherwise, it really doesn't matter. However, you're best bet is to always configure the system properly for your evnironment. So, all dates should have a D type format, preferably the same on all fields, so pick one an use it everywhere.

Remember, indexes work on the iconv value not the oconv value. so that's what you want to look at.

As for the import things, I think they'll do their typical bit. Start of strong, choke in the mid-season, then fight hard to gain a playoff spot in the last 3 games, then lose in the second round to a worse team after a series of stupid mistakes, dumb penalties and one crucial bad call by a ref. 74-75 was a long time ago, in a stadium far, far away…

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the Works forum...