Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
От | Robert Haas |
---|---|
Тема | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Дата | |
Msg-id | CA+TgmoaoiT68azOvVs9nWSQX7ov=CC3W0iFTY5cOQ=A6Mkpr_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jan 14, 2014 at 3:39 AM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Tue, Jan 14, 2014 at 5:08 AM, Hannu Krosing <hannu@2ndquadrant.com> wrote: >> Again, as said above the linux file system is doing fine. What we >> want is a few ways to interact with it to let it do even better when >> working with postgresql by telling it some stuff it otherwise would >> have to second guess and by sometimes giving it back some cache >> pages which were copied away for potential modifying but ended >> up clean in the end. > > You don't need new interfaces. Only a slight modification of what > fadvise DONTNEED does. Yeah. DONTREALLYNEEDALLTHATTERRIBLYMUCH. > This insistence in injecting pages from postgres to kernel is just a > bad idea. At the very least, it still needs postgres to know too much > of the filesystem (block layout) to properly work. Ie: pg must be > required to put entire filesystem-level blocks into the page cache, > since that's how the page cache works. At the very worst, it may > introduce serious security and reliability implications, when > applications can destroy the consistency of the page cache (even if > full access rights are checked, there's still the possibility this > inconsistency might be exploitable). I agree with all that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: