On Sat, Feb 25, 2012 at 5:54 PM, Stefan Keller <sfkeller@xxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
