Searching - Changing "Sort By"

[fuckyouraw777]

 

When one searches there is sometimes or all the time a 15 second delay; I understand why this would be so but changing the search from "relevancy" to "date" uses the same search terms but issues a different order by ... and gets hit by the same 15 second delay.

It seems that the default results are sorted by relevancy but sometimes date (newest first) might be the best results which gets hit by...the 15 second delay which seems to reset the timer.

TL;DR I can get into a loop of hitting a 15 second delay when all I want to do is reorder the results.

[fuckyouraw777]

Bah! I think I've got this in the wrong forum but I have NFI how to delete it myself 😞

[drscorpio]

5 hours ago, fuckyouraw777 said:

Bah! I think I've got this in the wrong forum but I have NFI how to delete it myself 😞

No, this is where it belongs. 

[BootmanLA]

On 12/19/2020 at 4:43 AM, fuckyouraw777 said:

 

When one searches there is sometimes or all the time a 15 second delay; I understand why this would be so but changing the search from "relevancy" to "date" uses the same search terms but issues a different order by ... and gets hit by the same 15 second delay.

It seems that the default results are sorted by relevancy but sometimes date (newest first) might be the best results which gets hit by...the 15 second delay which seems to reset the timer.

TL;DR I can get into a loop of hitting a 15 second delay when all I want to do is reorder the results.

I suspect that's because there are two ways, essentially, to handle the concept you're talking about.

The simpler way, and the way things are most usually implemented, is that each time you change a search parameter (including search order) the search is resubmitted to the database. Full-text searching (that is, looking for words or phrases as used within posts) is one of the most computer-intensive tasks for something like this, because the entire post has to be indexed for searching. (On something like Amazon, by contrast, all the assorted text within an item's description is not indexed or searchable; typically, it's the description, the seller, location, and a few other key fields, so even though there's far more data, the indexes are structurally much simpler.)

The reason for the "pull fresh data every time" is that's how the web was designed to operate. When you access a page of content from the provider, it sends whatever results it's supposed to send (unless there's an error), and then the connection ends. If you choose "sort by date" afterward, then the server on the other end has already moved on; it has to retrieve the data again sorted with the new parameters, then give you updated output.

Sometimes you'll see sites, however, that retrieve the data once, and then allow you to re-sort the results immediately by clicking on one of the column heads, or whatever. That's dependent on the language/development environment for the site. Those tools each work in different ways to fake keeping the data connection "live" so that re-sorts are almost instantaneous. But doing that requires an environment that supports that, first, and then it must be implemented by the developer.

[fuckyouraw777]

Full text searching, if you're using the right tool for the job (and an SQL server of any description is usually the WRONG tool for that job even though they CAN do it...just not as well as something like Lucene / Elastic Search / Apache Solr or one of the document DBs) can be surprisingly efficient and fast; I did mention I can understand the rationale behind delay (or to be more precise, the various rationales - I suspect there is more than one)...

Another way to say what I really mean is: it is difficult to reorder results -- and the EASIEST solution to that might be to add a ORDER RESULTS BY: [relevance, date, poster name] drop down on the search screen itself (so if you don't want it ordered by relevance, you can choose date up front and not have to change it again).