> > Even with true fdatasync it's not obviously good for performance - it takes
> > too long time to write 16Mb files and fills OS buffer cache
> with trash-:(
> >>
> >> True. But at least the write is (hopefully) being done at a
> >> non-performance-critical time.
>
> > So you have non criti
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Even with true fdatasync it's not obviously good for performance - it takes
> too long time to write 16Mb files and fills OS buffer cache with trash-:(
>>
>> True. But at least the write is (hopefully) being done at a
>> non-performance-criti
> > Even with true fdatasync it's not obviously good for performance - it takes
> > too long time to write 16Mb files and fills OS buffer cache with trash-:(
>
> True. But at least the write is (hopefully) being done at a
> non-performance-critical time.
So you have non critical time every fiv
> > Imho this write at logfile init time adds a substantial amount of IO,
> > that would better be avoided. If we really need this, it would imho
> > be better to preallocate N logfiles and reuse them after checkpoint.
>
> Already done. See the WAL_FILES parameter.
I meant something else. I d
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Imho this write at logfile init time adds a substantial amount of IO,
> that would better be avoided. If we really need this, it would imho
> be better to preallocate N logfiles and reuse them after checkpoint.
Already done. See the WAL_FILES
