Open GoogleCodeExporter opened 9 years ago
1. In case of using fetch first when assert high_mark is greater than zero and
low_mark is zero makes perfect sense. But in DB2 except using ROW_NUMBER we do
not
have a way when both low_mark and high_mark are non-zero. One option for us is
to
segregate the implementation and breaking it down to 2 cases:-
a) When low_mark = 0 and high_mark> 0 then we can use fetch_first
b) When both low_mark and high_mark are greater than zero then we are selecting a
small portion of the rows to be fetched and thus need to use ROW_NUMBER where
rownum>=low_mark and row_num<=high_mark
This case would make code little more complex but I guess most of the cases
would
have low_mark=0 and thus would optimize performance. I would take this up for
the
next release.
2) As you mentioned the case where django side changes. We certainly are bound
by
django implementations and limitations that DB2 has with limit/offsets. Like
for
example you cannot AS foo in a subquery formed by row_number. So, yes this is a
limitation and we hold on to till either DB2 brings out new features for
limit/offset
or Django changes implementation(I cannot think of a usecase when that might
happen
though.)
Original comment by tarun.pa...@in.ibm.com
on 1 Jul 2009 at 8:46
Original comment by rahul.pr...@in.ibm.com
on 12 Nov 2009 at 12:03
Original issue reported on code.google.com by
trebor74hr@gmail.com
on 26 Jun 2009 at 9:23