• Koen Verbeeck (4/2/2014)


    GilaMonster (4/1/2014)


    In-memory OLTP (hekaton) is for heavy concurrent load (tens of thousands of concurrent connections with thousands of inserts/sec). The advantage is the lock-less, latch-less optimistic concurrency. It's not a silver bullet for performance in all circumstances.

    Another (smaller) advantage is that you can mark tables as memory-only, so you don't have any IO to the disk subsystem at all. Downside is that you lose the data when SQL Server shuts down. Could be ideal for staging tables though.

    Or... a Tally Table and a Calendar Table... but only if things don't slow down that way. 😛

    Shifting gears, I'm really surprised to hear that anything dealing with Hekaton might be a little slower regardless of use.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)