Metacat Performance: paged Query Returns
If a query returns more than n results, then only n results should be shown to
the user at a time. This functionality is similar to a commercial search engine
that only shows the user "results 1-25" then you click a "next 25" button to get
to the next page of results.
#5 Updated by Saurabh Garg almost 16 years ago
Comment from bug# 2156:
Comparing Metacat with other search engines, there is a major
difference in the metacat web interface when compared to others. We
dont divide the result into blocks. So any online search will show x
number of results at a time. Metacat on the other hand shows all
results in one go. I am not sure how to fix this yet but I think we
will improve on time in three ways: database processing time, network
time and rendering of data in the browser. KNB currently has 1600
documents+ and a % search sends back a webpage which is 1.45 MB in
size. Hence even if we think of broadband, that is a lot of data being
sent back. Same goes for rendering of 1600 documents as compared to
10/20 documents. I am not sure though how hard this will be to implement
#6 Updated by Saurabh Garg almost 15 years ago
The query will probably to be stored on per session basis. Maybe the docids found can be stored in a ordered data structure in the session for each of the clients..
But there has to be a query id also as there might be multiple queries coming in from a client.. hence there might be multiple datasets to store. Hence all the skins and morpho when using paged query returns will have to be modified to include the query id assigned by metacat in there request of next set of results.
#7 Updated by Matt Jones over 14 years ago
See http://www.devx.com/Java/Article/21383/1954?pf=true for an excellent discussion of strategies for query paging using JDBC.
#8 Updated by Chad Berkley over 14 years ago
Metacat now does paged query returns. It also caches the last query with the user's session so that it does not need to re-run the entire query to re-display results. The cache can easily be cleared by running a different query then running the original query if you want to make sure you have the newest results. This works for public and authenticated sessions. I'll leave this bug open for now in case there are any problems that crop up with this solution later.