Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
| От | Andres Freund |
|---|---|
| Тема | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |
| Дата | |
| Msg-id | 4B6965F8.7040106@anarazel.de обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) (Greg Stark <gsstark@mit.edu>) |
| Список | pgsql-performance |
On 02/03/10 12:53, Greg Stark 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. I vote for two seperate apis - sure, there will be some unfortunate overlap for most unixoid platforms but its sure better possibly to allow adding more platforms later at a centralized place than having to analyze every place where the api is used. Andres
В списке pgsql-performance по дате отправления: