Re: MMAP Buffers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: MMAP Buffers
Date
Msg-id BANLkTin9yF-JfbOGBDf82KMvA8bVatufzA@mail.gmail.com
Whole thread Raw
In response to Re: MMAP Buffers  (Robert Haas <robertmhaas@gmail.com>)
Responses The big picture for patch submission (was Re: MMAP Buffers)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Apr 16, 2011 at 9:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Apr 16, 2011 at 2:33 PM, Joshua Berkus <josh@agliodbs.com> wrote:
>> Well, given the risks to durability and stability associated with using MMAP, I doubt anyone would even consider it
fora 10% throughput improvement.  However, I don't think the test you used demonstrates the best case for MMAP as a
performanceimprovement. 
>
> Actually, I'd walk through fire for a 10% performance improvement if
> it meant only a *risk* to stability.  The problem is that this is
> likely unfixably broken.  In particular, I think the first sentence of
> Tom's response hit it right on the nose, and mirrors my own thoughts
> on the subject.  To have any chance of working, you'd need to track
> buffer pins and shared/exclusive content locks for the pages that were
> being accessed outside of shared buffers; otherwise someone might be
> looking at a stale copy of the page.

Of course, maybe the patch is doing that.  Rereading the thread, I
grow increasingly confused about what this is actually supposed to do
and how it's supposed to work and why it's supposedly better than what
we do now.  But please, everyone feel free to continue bashing me for
wanting a readable patch with some understandable submission notes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: MMAP Buffers
Next
From: Jean-Pierre Pelletier
Date:
Subject: Re: ALTER TABLE INHERIT vs collations