AS far as I understand letting the user decide "Newest first -or- Oldest first" requires a large amount of re-work i.e. coding etc...

The options are there but are disabled. I am merely looking for a (What I think is a) short term solution, which would make many monks' searches a little more productive and if my thinking is correct more results would be reached in less queries thereby putting less load on the database.

I understand letting the user decide [...] requires a large amount of re-work

I have no idea where you got that impression. I said:

I'd like to support searching "newest nodes first" but the MySQL optimizer will likely fight me on this.

which has nothing to do with the amount of work involved.

Switching from always oldest first to always newest first is only a little less work than letting you choose between the two. The problem is that sorting on descending keys doesn't optimize very well in this version of MySQL (the documentation describes how this is caused by NULL values, but we don't have or even allow NULL values for that field so that shouldn't apply but testing shows that it certainly does).

So there is a moderate amount of work to put in support for searching most recent nodes first. But there is also a good chance that after that work is done the option will often be useless because the optimizer won't work well when you select that option and so your search will not be done.

So it is just a matter of someone finding the time. It isn't a priority because super search is very useful (at least to me) as it is, the work might well not pay off anyway, it isn't as much fun as some other items, and there are more important problems to deal with (to name a few reasons).

                - tye

Thank you for setting me straight and pointing to the more precise issue. Appologies if I mis-interpreted (tye)Re2: Newest Super Search, but I understood

Well, I tried to design it so that much of the time you can just fill in what you are searching for in that first box and then hit the button. But there needs to be some major work on how the results are presented after that.

to mean that considerable work would be required. I do not have an understanding of the MySQL optimizer and this is probably what created that impression.

On another note altogether, is there documentation on how yougo about testing patches or code for PerlMonks? If some-one found some spare time to look at possibly patching some of the PerlMonks code.. where could they start..?

-----
Of all the things I've lost in my life, its my mind I miss the most.