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