> > > http://slideshot.epfl.ch/play/suri_stonebraker > > > > > > > > > > > > He makes the claim that in a modern ‘big iron’ RDBMS such as > Oracle, > > > DB2, MS SQL Server, Postgres, given enough memory that the entire > > > database lives in cache, the server will spend 96% of its memory > > > cycles on unproductive overhead. This includes buffer management, > > > locking, latching (thread/CPU > > > conflicts) and recovery (including log file reads and writes). > > I think those numbers are overblown, and more PR than reality.
Did you check out the presentation? He presents figures obtained by experiment from instrumentation. Even if it's only 90% instead of 96%, he has a point. > But there certainly are some things that can be made more efficient if > you don't care about durability and replication. He cares plenty. Durability and high availability both rely on active replication. > > > I wondered if there are any figures or measurements on Postgres > > > performance in this ‘enough memory’ environment to support or > > > contest this point of view? > > I don't think that's really answerable without individual use-cases in > mind. Answering that question for analytics, operational, ... > workloads is going to look different, and the overheads are elsewhere. That's like: we don't have any figures for how fast your car will go: it depends on who's driving and how many passengers. My answer is: yes, of course, but you can still provide figures for some specific set of conditions, and they'll be better than none at all. > I personally think that each implementations restrictions are more > likely to be an issue than anything "fundamental". Unlikely. But you can still obtain figures. > > What limits postgresql when everything fits in memory? The fact that > > it's designed to survive a power outage and not lose all your data. > > > > Stonebraker's new stuff is cool, but it is NOT designed to survive > > total power failure. > > > > Two totally different design concepts. It's apples and oranges to > compare them. > > I don't think they're that fundamentally different. Agreed. Regards David M Bennett FACS Andl - A New Database Language - andl.org -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
