| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, rsmogura <rsmogura(at)softperience(dot)eu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 2nd Level Buffer Cache |
| Date: | 2011-03-18 21:13:43 |
| Message-ID: | AANLkTinTTJN8AW7F1oB3TefwQbt0fRxEb5M-ya7Ddgy=@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 18, 2011 at 2:15 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> +1
>
> To take the opposite approach... has anyone looked at having the OS just manage all caching for us? Something like MMAPed shared buffers? Even if we find the issue with large shared buffers, we still can't dedicate serious amounts of memory to them because of work_mem issues. Granted, that's something else on the TODO list, but it really seems like we're re-inventing the wheels that the OS has already created here...
The problem is that the OS doesn't offer any mechanism that would
allow us to obey the WAL-before-data rule.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-03-18 21:18:28 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
| Previous Message | Robert Haas | 2011-03-18 21:12:22 | sync rep & fsync=off |