113 reputation
4
bio website amadeus.com
location Sophia-Antipolis, France
age 30
visits member for 1 year, 9 months
seen Mar 13 '13 at 18:38

C++ software engineer for Amadeus since January 2010.

Avid follower of the Clang project.

Known to dabble in Python for scripting purposes.

Interested in language design, and thus very interested in Rust (typestate, concurrency) and interested in Haskell (type system, functional paradigm), which I unfortunately did not had time to explore yet...

Interested in compiler design and low-level technics: Memory Allocation/Garbage Collection, Compiler Optimizations, Link-time Optimizations.

Favorite answers of mine:

Favorite answers from others:


Mar
13
awarded  Scholar
Mar
13
accepted Fast paginated result, for various filter clauses
Mar
11
comment Fast paginated result, for various filter clauses
I managed to test your proposal, and indeed aligning the order by straigt on the index gets rid of the SORT step. Unfortunately, there is still a VIEW step right before the COUNT (STOPKEY) step... and therefore it's really costly. No cookie :x
Mar
9
comment Fast paginated result, for various filter clauses
Thanks for the latest proposition. I do plan on tracing all, we've got staging databases refreshed weekly with the state of their production database counterpart specifically so that we can test performance. Regarding the N-M difference, it is in the worst case capped at 250 for now; and we do plan on keeping much lower (~30) in most cases.
Mar
9
awarded  Supporter
Mar
9
comment Fast paginated result, for various filter clauses
Interesting. I can definitely add to the order by clause, as I said functionally it's redundant but I had not realized that Oracle could not understand it on its own. If I manage to get the STOPKEY it's also definitely worth it. However, with M = 4000 and N = 4030, it seems to still require reading a lot of rows (potentially all in-index though), right ?
Mar
9
comment Fast paginated result, for various filter clauses
@Mat: Don't I wish :( Unfortunately there is a reason for it: because we run systems that should not go down (and have penalties to pay for when they do), we settle for consistent and predictable over fastest available. I think stats collection are run manually from time to time (esp. on new tables after the volume stabilizes), but we are specifically asked not to rely on it.
Mar
9
awarded  Student
Mar
9
comment Fast paginated result, for various filter clauses
@Mat: corporate policy, stats collection is off and all queries must be hinted appropriately. I can add part_code (redundant with date) and func_col1 (once again not functionally relevant because of the =) in the order by clause if it helps.
Mar
9
asked Fast paginated result, for various filter clauses
Mar
9
awarded  Autobiographer