From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, dandl <david(at)andl(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: What limits Postgres performance when the whole database lives in cache? |
Date: | 2016-09-03 00:34:08 |
Message-ID: | CAH2-Wzn+6MN2uzD+2fRjb3vposaEsDykqswW1qdeLdBiwrhV+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Sep 2, 2016 at 10:32 AM, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | dandl | 2016-09-03 00:39:01 | Re: What limits Postgres performance when the whole database lives in cache? |
Previous Message | Jim Nasby | 2016-09-02 23:55:31 | Re: a column definition list is required for functions returning "record" |