> >> > 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. > > > > I personally think that each implementations restrictions are more > > likely to be an issue than anything "fundamental". > > +1 > > At one point, Stonebraker was regularly claiming that "crabbing" of > buffer locks in B-Trees was a fundamental overhead paid in systems > more or less based on System R. He did eventually start to acknowledge > that Lehman and Yao figured out a technique that made that untrue in > 1981, if only barely [1], but the lesson for me was to take his claims > in this area with a generous pinch of salt. > > [1] https://www.cs.cmu.edu/~pavlo/static/papers/stonebraker- > ic2e2014.pdf > (See his citation 11) The paper is substantially in agreement with the presentation I quoted. If there are differences in detail, they certainly don't dominate his argument. IMO your claim is far weaker. What specifically do you say is wrong about his current claims, and on what facts to you base it? In any event, I am not backing his claims. I am simply asking: does anyone have any facts to support or refute his 96% claim as applied to Postgres? Regards David M Bennett FACS Andl - A New Database Language - andl.org -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
