On Fri, Mar 26, 2004 at 07:25:53AM +0100, Manfred Spraul wrote:
> >Compare file sync methods with one 8k write:
> > (o_dsync unavailable)
> > open o_sync, write 6.270724
> > write, fdatasync13.275225
> > write, fsync, 13.359847
> >
> >
> Odd. Whic
On 26 Mar, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
>
>>Compare file sync methods with one 8k write:
>>(o_dsync unavailable)
>>open o_sync, write 6.270724
>>write, fdatasync13.275225
>>write, fsync, 13.359847
>>
>>
> Odd. Which fi
[EMAIL PROTECTED] wrote:
> On 26 Mar, Manfred Spraul wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>Compare file sync methods with one 8k write:
> >>(o_dsync unavailable)
> >>open o_sync, write 6.270724
> >>write, fdatasync13.275225
> >>write, fsync,
On 26 Mar, Bruce Momjian wrote:
> [EMAIL PROTECTED] wrote:
>> On 26 Mar, Manfred Spraul wrote:
>> > [EMAIL PROTECTED] wrote:
>> >
>> >>Compare file sync methods with one 8k write:
>> >>(o_dsync unavailable)
>> >>open o_sync, write 6.270724
>> >>write, fdatasync
[EMAIL PROTECTED] wrote:
Compare file sync methods with one 8k write:
(o_dsync unavailable)
open o_sync, write 6.270724
write, fdatasync13.275225
write, fsync, 13.359847
Odd. Which filesystem, which kernel? It seems fdatasync is broken and
On 22 Mar, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I could certainly do some testing if you want to see how DBT-2 does.
>> Just tell me what to do. ;)
>
> Just do some runs that are identical except for the wal_sync_method
> setting. Note that this should not have any impact on SELECT
> pe
Bruce,
> We don't actually extend the WAL file during writes (preallocated), and
> the access/modification timestamp is only in seconds, so I wonder of the
> OS only updates the inode once a second. What else would change in the
> inode more frequently than once a second?
What about really big w
[EMAIL PROTECTED] wrote:
> > I've made a test run that compares fsync and fdatasync: The performance
> > was identical:
> > - with fdatasync:
> >
> > http://khack.osdl.org/stp/290607/
> >
> > - with fsync:
> > http://khack.osdl.org/stp/290483/
> >
> > I don't understand why. Mark - is there a b
On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>
>>[EMAIL PROTECTED] writes:
>>
>>
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>>
>>>
>>
>>Just do some runs that are identical except for the wal_sync_method
>>setting. Note that
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I could certainly do some testing if you want to see how DBT-2 does.
Just tell me what to do. ;)
Just do some runs that are identical except for the wal_sync_method
setting. Note that this should not have any impact on SELECT
performance, only ins
[EMAIL PROTECTED] wrote:
> On 18 Mar, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> >> 1) This is an OSS project. Why not just recruit a bunch of people on
> >> PERFORMANCE and GENERAL to test the 4 different synch methods using real
> >> databases? No test like reality, I say
[EMAIL PROTECTED] writes:
> I could certainly do some testing if you want to see how DBT-2 does.
> Just tell me what to do. ;)
Just do some runs that are identical except for the wal_sync_method
setting. Note that this should not have any impact on SELECT
performance, only insert/update/delete pe
On 18 Mar, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> 1) This is an OSS project. Why not just recruit a bunch of people on
>> PERFORMANCE and GENERAL to test the 4 different synch methods using real
>> databases? No test like reality, I say
>
> I agree --- that is like
I wrote:
> Note, too, that the preferred method isn't likely to depend just on the
> operating system, it's likely to depend also on the filesystem type
> being used.
>
> Linux provides quite a few of them: ext2, ext3, jfs, xfs, and reiserfs,
> and that's just off the top of my head. I imagine th
Tom Lane wrote:
> > It really just shows whether the fsync fater the close has similar
> > timing to the one before the close. That was the best way I could think
> > to test it.
>
> Sure, but where's the "separate process" part? What this seems to test
> is whether a single process can sync its
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, I wrote the program to allow testing. I don't see a complex test
> > as being that much better than simple one. We don't need accurate
> > numbers. We just need to know if fsync or O_SYNC is faster.
>
> Faster than what? The
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, I wrote the program to allow testing. I don't see a complex test
> as being that much better than simple one. We don't need accurate
> numbers. We just need to know if fsync or O_SYNC is faster.
Faster than what? The thing everyone is trying to
Josh Berkus <[EMAIL PROTECTED]> writes:
> 1) This is an OSS project. Why not just recruit a bunch of people on
> PERFORMANCE and GENERAL to test the 4 different synch methods using real
> databases? No test like reality, I say
I agree --- that is likely to yield *far* more useful result
Tom, Bruce,
> My previous point about checking different fsync spacings corresponds to
> different assumptions about average transaction size. I think a useful
> tool for determining wal_sync_method has got to be able to reflect that
> range of possibilities.
Questions:
1) This is an OSS project
19 matches
Mail list logo
