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
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
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
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,
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