From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Filesystem Direct I/O and WAL sync option |
Date: | 2007-07-04 10:26:10 |
Message-ID: | 5482c80a0707040326v1229f11dh2a69278365c1de8c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Yes Gregory, that's why I'm asking, because from 1800 transactions/sec
I'm jumping to 2800 transactions/sec! and it's more than important
performance level increase :))
Rgds,
-Dimitri
On 7/4/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> "Dimitri" <dimitrik(dot)fr(at)gmail(dot)com> writes:
>
> > Yes, disk drives are also having cache disabled or having cache on
> > controllers and battery protected (in case of more high-level
> > storage) - but is it enough to expect data consistency?... (I was
> > surprised about checkpoint sync, but does it always calls write()
> > anyway? because in this way it should work without fsync)...
>
> Well if everything is mounted in sync mode then I suppose you have the same
> guarantee as if fsync were called after every single write. If that's true
> then surely that's at least as good. I'm curious how it performs though.
>
> Actually it seems like in that configuration fsync should be basically
> zero-cost. In other words, you should be able to leave fsync=on and get the
> same performance (whatever that is) and not have to worry about any risks.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-07-04 10:45:01 | Re: Filesystem Direct I/O and WAL sync option |
Previous Message | Axel Rau | 2007-07-04 07:30:24 | Re: Delete Cascade FK speed issue |