> Wayne Piekarski <wayne@senet.com.au> writes:
> > I already have the -o -F switch in the startup file (which I believe is
> > working) but I'm under the impression from what I read that there are two
> > fsync's - one you can switch off, and one which is fixed into the code
> > and possibly can't be removed?
>
> No. I've looked.
>
> Actually there is an un-disablable fsync() on the error file in elog.c,
> but it's not invoked under ordinary scenarios as far as I can tell,
> and it shouldn't be a performance bottleneck anyway. *All* the ordinary
> uses of fsync go through pg_fsync.
I had a dig through the source code yesterday and witnessed the same thing
as well, each call is controlled with -F. However, I did mess up when I
wrote my previous email though, because I don't have -F enabled right now,
so I am running with the fsync() turned on, which makes sense and explains
what is happening with the cache.
After reading the mailing list I was under the impression this fsyncing
was different from the one controlled by -F.
I am going to be taking it for a test tonight with -F enabled to observe
how much better the performance is. Hopefully it will cache better as a
result of this, I guess I'll have to run it like this from now on.
thanks,
Wayne
------------------------------------------------------------------------------
Wayne Piekarski Tel: (08) 8221 5221
Research & Development Manager Fax: (08) 8221 5220
SE Network Access Pty Ltd Mob: 0407 395 889
222 Grote Street Email: wayne@senet.com.au
Adelaide SA 5000 WWW: http://www.senet.com.au