Sqlpaging Fine Control - Paging without use of Limits

[iainc.dev]

I've turned on paging on a listgrid, as follows:

lgPSMs.setDataFetchMode(FetchMode.PAGED);

I'm using a MySQL-like columar db. However, because queries can take up to a couple minutes to execute (and because of the way columnar datbases work), I

1) do *NOT* want to first do a "select count(*)" to determine the number of rows
2) do *NOT* want to use "limit" statements in the SQL, since each SQL will take a few minutes to run.

Instead, I want to run the *whole* SQL once, cache the enitre result set (eg all 1000 rows) and then only give back to the client the request page (eg rows 0 through 74, assuming our page size remains at the default of 75.)

However, I can't figure out how to do this properly. I've tried various options. Thus far, I've tried this:

In server.properties, I've added the following terms:

sql.defaultCustomSQLPaging: dropOnServer
sql.defaultPaging: dropOnServer

And, I've implemented it so that the first dsRequest (which will have an end-row of 75 I believe by default) fires off a second dsRequest. In this second dsRequest, I"ve set the sqlPaging behaviour to "none", as follows:

<operationBinding operationType="fetch" operationId="fetchPeptidesSlave" sqlPaging="none" 

			outputs=<blah, blah, blah...>
		</operationBinding>

And then I've cached the results. However, it just doesn't seem to work. It seems to still send all 187 rows back to the client, instead of just sending the first 75. What am I doing wrong? Am I even using the right SmartGWT paramaters? Or using them in the "right" way to accomplish what I wish?



Additional details:
======================
SmartGWT (not smartclient) Version: SmartClient Version: v8.3p_2012-11-26/PowerEdition Deployment (built 2012-11-26)
...
Browser: Mozilla Firefox ESR 10.0.7
GWT SDK: 2.5.0rc2
Sun JDK 1.6.0_13
OS: Centos 6.x
IDE: MyEclipse 10.6 with Google Plugin for Eclipse (3.1.0)

[Isomorphic]

From a performance perspective, if you are planning to pull all 1000 rows to Java, and each user is going to be looking at a different set of rows, you probably do not want to cache these on the server - just pass them straight through to the client.

Server-side caches mean a very large per-user footprint in server memory. Client-side caches leverage the memory in each end-user's machine.

If you plan to do server caching anyway (maybe the rows are static and sharable between all users), if you just execute() a new DSRequest server-side without setting startRow or endRow it will fetch all rows without attempting a limit query.