Re: API Method GetFavorites()

I will release a change to GetFavorites() the coming days.

A while back I made changes to GetOldestCaches/GetHighestCaches/GetLowestCaches so that the script writer can choose which DB cluster to use, by setting alternativeDBCluster to true (false is default).

When setting it to true a DB cluster better at digging deep and processing lots of data will be used. But leaving it to false is better if DB indexes can be used well.

The reason to the change was triggered by https://project-gc.com/forum/read?8,85610,85610.

So currently GetFavorites() defaults to the alternative DB cluster. With the new patch it will instead default to the standard cluster. If you know you are using the function in cases where country isn't used for filter, it might be worth testing and comparing speed between the two clusters.

Howdy,

I just got an introduction to this. Is there a description of what the indices currently cover so we can better understand when to use the different modes?

Thanks.

I don't think it can be told in a way that a human can for sure guess what's smartest. It's best to test.

When set to true it's using a fully indexed data set. It's a column based database engine. It's just as fast regardless of how your query is more or less. It means that it will be slower than a normal row based database is (when using false) when those indexes works in your favor. But a lot faster in the other cases.

If you have a script that needs to ask almost the same query multiple times, it's likely that you won't make it with the column based database, instead you will need a query that matches indexes.

The problem is that for some checkers indexes doesn't really help, because they still query half the database, and then the database will choose to me a full scan regardless.

Row based is likely to be faster every time there is a country used that can hit a index, but maybe not if it's a list of all countries in Europe for example.