| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Joshua Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Radosław Smogura <rsmogura(at)softperience(dot)eu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: MMAP Buffers |
| Date: | 2011-04-17 01:31:46 |
| Message-ID: | BANLkTi=6s8dJfgZjtRF6-XXmoxx7q2-=MQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 16, 2011 at 2:33 PM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> Well, given the risks to durability and stability associated with using MMAP, I doubt anyone would even consider it for a 10% throughput improvement. However, I don't think the test you used demonstrates the best case for MMAP as a performance improvement.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-04-17 01:39:03 | Re: MMAP Buffers |
| Previous Message | Andrew Dunstan | 2011-04-17 01:24:44 | Re: Formatting Curmudgeons WAS: MMAP Buffers |