Re: What limits Postgres performance when the whole database lives in cache?
От | Peter Geoghegan |
---|---|
Тема | Re: What limits Postgres performance when the whole database lives in cache? |
Дата | |
Msg-id | CAH2-Wzn+6MN2uzD+2fRjb3vposaEsDykqswW1qdeLdBiwrhV+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: What limits Postgres performance when the whole database lives in cache? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: What limits Postgres performance when the whole database lives in cache?
|
Список | pgsql-general |
On Fri, Sep 2, 2016 at 10:32 AM, Andres Freund <andres@anarazel.de> wrote: > >> > 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) -- Peter Geoghegan
В списке pgsql-general по дате отправления: