[sqlalchemy] Re: new LIMIT/OFFSET Support for oracle - huge speed penalty

2010-07-07 Thread Ralph Heinkel
Hi, sorry for the late reply. I've now made some measurements, and repeated those two a couple times to avoid caching effects. I've reduced it to the innermost sql statement. Here they are: SELECT entrypoint_id, ...<20 about fields> ..., ROW_NUMBER() OVER (ORDER BY creationdate DESC, entrypoint_i

Re: [sqlalchemy] Re: new LIMIT/OFFSET Support for oracle - huge speed penalty

2010-06-26 Thread Michael Bayer
On Jun 24, 2010, at 6:23 AM, Ralph Heinkel wrote: > I checked the results (for my case) for the two variants of ordering > our table > (actually a view) and I could not find any difference. No duplicates, > everything in > same order. > > Next monday I can provide you with some benchmarks. Some

Re: [sqlalchemy] Re: new LIMIT/OFFSET Support for oracle - huge speed penalty

2010-06-24 Thread Michael Bayer
On Jun 24, 2010, at 6:31 AM, Ralph Heinkel wrote: > Hi Michael, > > We have also tried the /*+ FIRST_ROWS(N) */ optimization hint, it > only gave a 25% speed improvement, but the result was still 5 or 7 > times slower than the ROW_NUMBER() OVER approach. > I'll provide benchmark details on Mon

[sqlalchemy] Re: new LIMIT/OFFSET Support for oracle - huge speed penalty

2010-06-24 Thread Ralph Heinkel
Hi Michael, We have also tried the /*+ FIRST_ROWS(N) */ optimization hint, it only gave a 25% speed improvement, but the result was still 5 or 7 times slower than the ROW_NUMBER() OVER approach. I'll provide benchmark details on Monday, also details about table (actually a view) layout, indices,

[sqlalchemy] Re: new LIMIT/OFFSET Support for oracle - huge speed penalty

2010-06-24 Thread Ralph Heinkel
I checked the results (for my case) for the two variants of ordering our table (actually a view) and I could not find any difference. No duplicates, everything in same order. Next monday I can provide you with some benchmarks. Some more details: - the select was run on a view with 20 columns, comi