Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |
Дата | |
Msg-id | 603c8f071002030542r779a4f47k78355c62b0b7853@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1
ubuntu karmic slow createdb)
|
Список | pgsql-performance |
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark <gsstark@mit.edu> wrote: > On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I think you're probably right, but it's not clear what the new name >> should be until we have a comment explaining what the function is >> responsible for. > > So I wrote some comments but wasn't going to repost the patch with the > unchanged name without explanation... But I think you're right though > I was looking at it the other way around. I want to have an API for a > two-stage sync and of course if I do that I'll comment it to explain > that clearly. > > The gist of the comments was that the function is preparing to fsync > to initiate the i/o early and allow the later fsync to fast -- but > also at the same time have the beneficial side-effect of avoiding > cache poisoning. It's not clear that the two are necessarily linked > though. Perhaps we need two separate apis, though it'll be hard to > keep them separate on all platforms. Well, maybe we should start with a discussion of what kernel calls you're aware of on different platforms and then we could try to put an API around it. I mean, right now all you've got is POSIX_FADV_DONTNEED, so given just that I feel like the API could simply be pg_dontneed() or something. It's hard to design a general framework based on one example. ...Robert
В списке pgsql-performance по дате отправления: