On Sat, Feb 25, 2012 at 5:54 PM, Stefan Keller <sfkeller@gmail.com> wrote:
> Hi,
>
> Recently Mike Stonebraker identified four areas where "old elephants"
> lack performance [1]:
>
> 1. Buffering/paging
> 2. Locking/Multithreading
> 3. WAL logging
> 4. Latches (aka memory locks for concurrent access of btree structures
> in buffer pool?).
>
> He claims having solved these issues while retaining SQL and ACID.
> But the only issue I understood is #1 by loading all tuples in-memory.
> => Are there any ideas on how to tell Postgres to aggressively load
> all data into memory (issue #1)?
>
> All remaining issues make me wonder.
> I actually doubt that there are alternatives even theoretically.
> => Can anyone help explaining me issues 2,3 and 4, their solutions,
> and why Postgres would be unable to resolve them?
>
> Yours, Stefan
>
> [1] "NewSQL vs NoSQL for New OLTP", NoSQLNow! Conference, August 2011.
> http://voltdb.com/resources/videos
Here's a great speech he gave at the USENIX conference:
http://www.youtube.com/watch?v=uhDM4fcI2aI
Basically he makes the point that IF your dataset fits in memory and
you need fast performance, then using multiple machines like a RAID
array with everything in memory beats everything out there, and that's
the methodology he's shooting for.
For super fast transactional systems that fit in memory, I can see the
advantage of moving everything into memory and using redundant
servers, possibly geographically distant from each other, to ensure
durability.
But he does make the point as well that for LARGE systems that need
transactional integrity, there's still nothing that beats an elephant
like system.
BTW, there's some other great presentations at that conference as
well. The one or two about btrfs from an oracle guy are quite
fascinating.