Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Lasse_Lus]

i have done some research regarding searchlist & searches and speed and i'm a little bit confused about the answer.

i have always thought that if i have a view with a filter ie media type ="Audio" and in the view i have a searchlist that shows for example missing files, MC will only look at the files in that view that are already filtered out or requery the database with the filterquestion first, but if I check the logs i can see that it query the hole database and then filter out the view..and it's the same for "box searches", it takes time..

examples

1993625: 6056: Database: CMJSearchHelper::GetResults: Search: [Album]=[Topalbums] -[Volume Name]=[S:] amandas ~sort=[Date Imported]-d; Elapsed ms: 267,410

2012891: 5596: Database: CMJSearchHelper::GetResults: Search: amandas [Album]=[Topalbums] -[Volume Name]=[S:] ~sort=[Date Imported]-d; Elapsed ms: 12768,965

according to this when i search for amanda in a already filtered view and if it was the other way around i would get the results about 8-10 times faster !!

if i understand this correctly i can have a database with 500 K files and some heavy expressions in a filtered view and still get very fast answers if the query was in a "correct" order

first: exclude access control then: the filtered view and then the query

or have i got it wrong ?

[Matt]

I'm not sure the exact question, but internally search ordering is important and can change performance.

The program tries to make smart choices automatically.  If you think there are cases where it's getting things wrong, please post some more details.

Thanks.

[Lasse_Lus]

ok matt, i try to be more clear and try to explain by example

in my custom view i use "Set Rules for file display", where I filter out what i want to see in the view, for example filetype = "ape".

in that view i use searchlists as categories to filter out stuff for example name = abba

shouldn't the searchlist inherit my custom viewfilter "filetype =ape" first and not after ?

so when i check the logs it seems that the query looks like this, (when selecting my searchlist filter)

name="abba" filetype="ape"      instead of: filetype="ape" name="abba"

so instead of doing a search on the already filtered data as in filetype=ape, it search the hole database for abba and then applying the filter filetype ="ape"

so this means that if i have complicated queries (not like above) in my searchlist i need to add the filter already in the view for every searchlist i add, there is significant difference in the speed about 10 times, but for a novice like me it does not feel right.

conclusion: the "Use parent scheme rules for file display" should come first instead of after ?


example nr 2 simple search

i have my custom view that is filtered out on filetype "ape" under "Set Rules for file display" and i search for abba in the searchbox up in the right corner

according to the logs it search for abba throughout the hole database and then applying the filter, instead of searching in the inherited already filtered out view.

the real "problem" for me is that i use a lot of "complicated" searchlists in the views and as i now know i have to set the complete filter/query in every searchlist instead of using the inherited topfilter, which means that it gets quite complicated to change stuff.

when i refer to the logs i mean that you can copy the strings from the logs into a smartlist and see the big difference, how the query acts against the database.

i know this is how it is and i'm not trying to push anything but i'm just curious if there would be a way to use the topfilters first in the queries, it would mean a big timesaver when you have complicated views and when administrating them.

thanks for listening //Lars

[gappie]

but for a novice like me

you are kidding. 
but it is an interesting post, lars. never thought about checking the times via the log. i think in most cases choosing the order in the searches is part of making a search list. that is true for outcome and speed alike. so, as in your first example, i would expect that the outcome is like you found.
now for the second example.. i think it would be nice to know how mc treats searches like that. what comes first, what comes second.
and there are some more instances where that could be usefull to know.
i sometimes wish there would be an option to disable a string in search list, and a easy way to change order, because in some cases, as you show, the differences in speed is huge. it would making and testing searches much easier.

im of to check some of my slower searches again.

 
gab

[hit_ny]

if i understand this correctly i can have a database with 500 K files and some heavy expressions in a filtered view and still get very fast answers if the query was in a "correct" order

It's always faster to narrow down the fields that get searched.

It's also faster to use brackets when possible instead of quotes.

Finally, "or" can be slow, so it'd be better to use a comma delimited list

[Lasse_Lus]

we know that hit_ny  please keep to the subject