Re: fallocate / posix_fallocate for new WAL file creation (etc...)
От | Jon Nelson |
---|---|
Тема | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Дата | |
Msg-id | CAKuK5J0JObq_y-LF311PVOaN-qx16O5j1BVNeErVdCQyE+WryQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fallocate / posix_fallocate for new WAL file creation (etc...) (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: fallocate / posix_fallocate for new WAL file creation
(etc...)
|
Список | pgsql-hackers |
On Fri, Jul 5, 2013 at 2:23 AM, Greg Smith <greg@2ndquadrant.com> wrote: > On 7/5/13 2:50 AM, Jeff Davis wrote: >> >> So, my simple conclusion is that glibc emulation should be about the >> same as what we're doing now, so there's no reason to avoid it. That >> means, if posix_fallocate() is present, we should use it, because it's >> either the same (if emulated in glibc) or significantly faster (if >> implemented in the kernel). > > > That's what I'm seeing everywhere too. I'm happy that we've spent enough > time chasing after potential issues without finding anything now. Pull out > the GUC that was added for default and this is ready to commit. Wonderful. Is removing the GUC something that I should do or should that be done by somebody that knows more about what they are doing? (I am happy to give it a go!) Should the small test program that I made also be included somewhere in the source tree? -- Jon
В списке pgsql-hackers по дате отправления: