If the searched columns are properly indexed, then it doesn’t matter how many columns are in the database. It is going to use the index to do the sorting and the filtering, then it is going to read the required columns only for the filtered rows.
Without indexes on the other hand, I don’t know it the database is smart enough to read only the columns involved in filtering and sorting or if it gets the whole row only to filter it out later. Databases are smart, but when they don’t find an index they may not care or be able to optimize the query.
In Anvil we don’t have complete freedom to generate any kind of indexes. I have a dedicated plan and I have 3 options per column. Here is what I see when I right click on a column header:
I would just make sure you are using the accelerated tables and you are getting only the columns you actually need, whether they are from linked tables or not. With accelerated tables you can specify what columns to get, including from linked tables, while with the old library (if I remember correctly) only columns of certain types are cached immediately, while accessing the other columns, including linked tables, requires one additional query. Per row!
Linked tables were so slow that I have religiously avoided them. It wasn’t the filtering or sorting part, it was accessing the linked table part, after the filtering. I haven’t created any new apps since the advent of accelerated tables, but I plan to give them and linked tables a try in my next app.