Paging

Paging enables you to view subsets of results, one page at a time, instead of retrieving and scrolling through the full result set. A page of results contains a subset of items from a potentially larger set of results.

To browse most the results from beginning to end, retrieve all results in one call on a large single page of results instead of paging. However, to browse a small subset of results, retrieve only a small set of results and request more as you need them. Each page request runs the same query as a non paged request or single large page request. Although running the query involves a performance cost that is constant whether you are using paging or not, you save the cost of data retrieval, transmitting, and rendering results for data on other pages and retrieve only the data for the page you are viewing. Retrieving the first page of results is much faster than retrieving the full set of results. The performance cost of retrieving each subsequent next page is progressively more than the previous page because of some overhead to process and skip past the previous page of results. Retrieving the last page of results is much more expensive than retrieving the first page, but the last page is still less expensive than retrieving the full set of results. However, browsing through all pages of results is more expensive than retrieving the full results instead of paging through them. Browsing through only a few pages of results can be more or less expensive than retrieving the full results depending on the query complexity, number of results, data size, transmission speeds, and rendering speeds. For example, the combined cost of a few pages can cost more than retrieving the full results. However with pages you do not have to wait as long for each page.

To minimize the number of pages you must browse through, sort the request so that the results you want are on the first page. For example, it is common to sort by last modified date in descending order to see the most recently active documents that you look for. You can also use a query that returns a smaller subset of results that you want on the first page. For example if you are running a saved search for documents you modified, use a saved search instead that finds documents that you modified last in the past 24 hours. Because the results are sorted by the database before paged, you can only sort on results that are guaranteed to be on all possible results for that query in the database. The sorting support varies by feature, by configuration settings, and by data. For example you can sort libraries by file name, but you cannot always sort saved searches by file name.

Some applications request paged results one page at a time, such as the custom library. Some applications allow you to change the page size so that you can select how large each page of results is. If you can change the page size, you can make a non paged request by requesting a large single page of results and get all results on the first page. If the application allows you to configure the default page size, you can select a page size that balances performance of first page rendering, user experience for the size of the page, and minimize the number of multiple page requests that are required.

IBM® CMIS for Content Manager supports paging of the following result lists: