Inefficient might not be a strong enough word 
4 Advanced filters with intersects and list operators? That will absolutely run your app to the ground.
As @rpetribu said, you need to move the filtering onto search constraints.
Advanced filters needs to be avoided on your main filtering operations. They are not run on the Servers, they are run on the client’s computer. Adv filters can be useful, but only on small numbers of things, typically on list fields of Things which you know have very few things, AND they should be filtering operations which are going to be hard to replicate by using search constraints or would require a big database design change.
Move all the search constraints onto the search. Is your search even constrained at all right now?
You might think this is not possible, but it always is.
The first one:
Change it to ** Newsletter Name contains Listado_minuscolas’s value capitalised.**
Make sure your Newsletter name is always capitalised when you save it to the database, Run :lowercase:Capitalised when you save it. If you really want to let users save Newsletter Names with weird capitalisations like BeSt NeWsLetTER in the WORLD, I would add a redundant field that saves the wonky text, but filter using the formatted text.
The Third & Fourth One:
Add a redundant field on the Newsletter which contains the Max Price and Min Price of its newsletter, and constrain on that. 100% justified redundant field and database change.
Make sure to keep that field maintained when the underlying Prices of ads change.
The Second One:
This is the trickiest because of many-to-many relationship. It’s also the one slowing down the search the most. Search the forums, this has been discussed before.
You might not like this answer.
Filtering based on list fields containing an element from a list is not good practice. Best approach is to create a junction dataType for newletters and categories. This means creating a new dataType which has a field for Newletter and a field for Category. If a newsletter has 5 categories, it would have 5 rows on this table, all sharing the same newsletter. This would allow you to run a search where the constraint reads: ‘Category is in List of Categories’, instead of having to run an advanced filter.
I would actually put all the fields on which you are filtering here, and use this dataType for the search, and then using Newsletter:unique elements to populate the Newsletters.
The above is industry good practice, but another way is to use a custom state to store the list of Newsletters and using the ‘:merged with’ / ‘remove list’ operators as user select/unselect categories.
Hope this helps.
I know its a lot to digest. But you probably need to find a way to reduce the long load. (Which will get much much worse with 1000s of things)
.
, as you mentioned, it took a while to digest, but we went point by point applying all your pieces of advice.
