From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MMAP Buffers |
Date: | 2011-04-15 11:33:37 |
Message-ID: | 4DA82D11.8030808@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.04.2011 13:32, Radosław Smogura wrote:
> If I may, I want to share some concept to use mmap in PG. It's far, far
> away from perfect, but it's keeps WAL before data. As well I crated
> table, with index, inserted few values, and I done vacuum full on this
> table. Db inits welcome from orginal sources.
>
> Performance of read (if backend is loaded) is really good, query time
> goes down from 450ms to about 410ms. Update may be slower - but work is
> in progress (I will start with write, as I went to point when simple
> updates may be performed). Even that I didn't covered all aspects off
> updating, it's simple to do it, just to call PreopareBufferToUpdate
> before modifing buffer, ofc some ideas of increasing this are still in
> my head.
>
> Any comments, suggestions welcome.
The patch is quite hard to read because of random whitespace changes and
other stylistic issues, but I have a couple of high-level questions on
the design:
* Does each process have its own mmappings, or are the mmapping done to
shared buffers?
* How do you handle locking? Do you still need to allocate a shared
buffer for each mmapped page?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-04-15 11:57:40 | Re: Single client performance on trivial SELECTs |
Previous Message | Radosław Smogura | 2011-04-15 10:32:37 | MMAP Buffers |