-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 01/11/2010 20:54, hubert depesz lubaczewski a écrit :
> On Mon, Nov 01, 2010 at 08:31:10PM +0100, Cédric Villemain wrote:
>> It should stick at a maximum of 3 * checkpoint_segments + 1, if it
>> exceed it will remove the extra files after.
>
> if you'd look at the graph you'd notice that it never goes down to 2n+1.
> And really - so far I have not yet heard/seen/read any solid reasoning
> for 3n instead of 2n.
I understand this 3n this way:
n "active" WAL files
n "recycled-ready-to-use" WAL files
checkpoint_completion_target*n WAL being write on disk
>
>>> also - can you explain why "fraction of total time" (time!) would
>>> directly relate to number of xlog files existing in pg_xlog? I mean -
>>> you're not the first person to suggest it, but I don't see any way that
>>> these two could be related.
>> It's guess that while your checkpoint is longer by this factor(X%),
>> the number of wal files needed might be multiplied by the same ratio.
>> (1+X%) To handle extra files created while the checklpoint is still
>> running.
>
> I'm not sure I understand. Will need to run some tests. Yet - even
> assuming (2 + checkpoint_completion_target ) * n - it doesn't explain
> why there was no difference in number of segments after decreasing from
> 0.9 to 0.5.
Does your cluster have enough write ? I think you might have to wait a
bit longer to see remaining files being recycled or deleted...
>
> Best regards,
>
> depesz
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzPHZcACgkQxWGfaAgowiKQnQCgg7HIAI35mlfySbYY/VptqyjQ
kIwAni9DtLqx4j7MFk//1cTf88Dul/4e
=NfHT
-----END PGP SIGNATURE-----
