Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
От | Claudio Freire |
---|---|
Тема | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Дата | |
Msg-id | CAGTBQpadbNnBp4F-0ac8wrYar+8dGUa85=pi35D1+pRSLDkPEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Список | pgsql-hackers |
On Tue, Jan 14, 2014 at 2:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > In terms of avoiding double-buffering, here's my thought after reading > what's been written so far. Suppose we read a page into our buffer > pool. Until the page is clean, it would be ideal for the mapping to > be shared between the buffer cache and our pool, sort of like > copy-on-write. That way, if we decide to evict the page, it will > still be in the OS cache if we end up needing it again (remember, the > OS cache is typically much larger than our buffer pool). But if the > page is dirtied, then instead of copying it, just have the buffer pool > forget about it, because at that point we know we're going to write > the page back out anyway before evicting it. > > This would be pretty similar to copy-on-write, except without the > copying. It would just be forget-from-the-buffer-pool-on-write. But... either copy-on-write or forget-on-write needs a page fault, and thus a page mapping. Is a page fault more expensive than copying 8k? (I really don't know).
В списке pgsql-hackers по дате отправления: