On May 27, 2007, at 2:09 PM, Aristedes Maniatis wrote:


I don't quite understand what 'resolvesFirstPage()' refers to. Does it mean 'firstPageResolved()'? Should it be negated here:

No. "resolvesFirstPage" really a shorthand for "is it possible to reliably resolve objects on the first page using the existing algorithm".


In some circumstances this is true, in some (like yours) it is clearly not. I am leaning towards making a second strategy the default, as paginated queries are really intended for the huge result sets... Anybody has other thoughts on that?

Without a LIMIT on the records which are fetched as a 'fat query' there is little point in paging at all I think.

Not true. Compare the timing of the paginated vs. normal query on your data set - you should see a big difference. (Also do not use the time printed in Cayenne SQL logs, as this is for the SQL part only; do the timing yourself, around "performQuery" method). In fact our original performance testing back when the paginated query was implemented showed very little difference between "select *" and "select id", so this bottleneck may actually be DB-specific.

Again, I am for updating the default algorithm, but I still think this is an edge case, and we need to do some JDBC performance testing to prove that such change can fix it.

We timed this query against the db and even directly without Cayenne it takes 16 seconds to return all the data. I presume the next 24 seconds Cayenne spends parsing the results into DataRows or Objects. Instead, if we executed:

SELECT t0.id FROM Student t0 WHERE (t0.isDeleted IS NULL) OR (t0.isDeleted = 0) ORDER BY t0.firstName

Then it returns in about 2 seconds

Just to confirm, is this a JDBC test or a test using DB client tools (on Derby this may be the same thing, still worth doing a JDBC run with your own code, as there can be unrelated bottlenecks in the tools). E.g. create two PreparedStatements, one with "select *", another with "select id", and only read "id" column in both resultsets. See how much faster the second case is.

Andrus

Reply via email to