On Wed, 20 Jan 1999, Valerio Gelpi wrote:
>> I was wondering if you are planning to add the feature to be able to have
>> multiple result pages. I was able to implement such feature thanks to
>> Schultz (email@example.com) changes to a few Swish files. I would
>> assume such a feature to be natural for this program.
To which Roy Tennant replied"
>We were thinking that this function could logically reside outside
>SWISH-E, in the hands of the program manipulating the results. What do
>others think about this?
On the face of it, you're correct. My experience (and the reason that I
the patch to skip X initial results) was that the performance gain was a
lot higher if swish-e set the initial starting point for me.
Consider a search that returns 1000 results. I want to present these results
to the user 100 at a time. No problem. I just stick the results in an array
in Perl or PHP and start at the X-hundredth element, or I read the output
skip X-hundred lines. Since I don't have state maintained between pages
I have to do the search again on each page in order to display the next page
What I found was that doing the search ten times was not nearly as
as reading all the results ten times and "positioning the cursor", to borrow
database parlance. Swish-e already has -m to restrict the number of results
It was a natural fit (IMO) to add a parameter to tell where in the results
start the display.
By having swish-e return only 100 results each time, (by skipping to the
start and then only displaying 100) my scripts don't have to read a lot of
that isn't neccesary and I don't have to allocate giant arrays to handle
sets of results if someone searches our jobs database for something generic
"software". The search is fast, the display is fast, and the only state I
to maintain is the current position of the "cursor" and the page-size.
It's a practical thing rather than an elegance thing. You're right about
it not being directly related to the index/search functionality of
swish-e. However, it is an extension of existing functionality (ability to
limit results) and it's needed for the same reasons that the -m flag
was needed. One could as easily argue that the -m functionality should be
handled by the wrapper script; it's just a heck of a lot faster and
less resource-intensive to have swish-e handle it instead.
Received on Fri Jan 22 11:52:08 1999