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

C++ software engineer for Amadeus since January 2010.

Avid follower of the Rust project, and still following Clang/LLVM (which I helped improved a bit with -Wdelete-non-virtual-dtor).

Known to dabble in Python for scripting purposes.

Interested in language design, and thus very interested in Rust (zero-cost memory safety, zero-cost data-race safety, 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:


Jan
14
awarded  Popular Question
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