From: | Stéphane BUNEL <stephane+pgfr(at)bpf(dot)st> |
---|---|
To: | Francis Leboutte <f(dot)leboutte(at)algo(dot)be> |
Cc: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: taille fichiers BD, RAM, performance |
Date: | 2007-11-16 16:33:18 |
Message-ID: | 473DC64E.5090707@bpf.st |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Francis Leboutte a écrit :
> Le 16/11/2007 16:58, Guillaume Lelarge écrivait :
>> Francis Leboutte a écrit :
>> > Merci à tous pour les réponses.
>> >
>> > J'ai oublié de dire que comme la taille du répertoire de ma BD fait
>> > 70Mo, je m'attendais à un
>> > heap_blks_read = 0
>> >
>> > SHOW shared_buffers; montre bien "50000"
>> >
>> > Pas moyen d'atteindre cette valeur 0?
>> >
>>
>> Euh... comment peut-il mettre en cache la table s'il ne la lit pas ?
>> parce que les premières lectures concernant la mise en cache (il n'y a
>> peut-être pas que ça dans les lectures indiquées, mais il y a au moins
>> ça... vous n'obtiendrez *jamais* 0).
>
> Je suppose (et il me semble l'avoir lu) qu'à un moment ou l'autre les
> données statistiques sont rénitialisées (toutes les X secondes ou à la
> fin ou au début d'une transaction). Comme je répète régulièrement le
> même test (± 5000 fois une série de 30 select, le 0 devrait être atteint
> à la longue.
Non, c'est un compteur qui ne peut que s'incrémenter.
Mettez votre base sur un système de ficher en RAM et oubliez les
statistique, votre base sera pour le coup en mémoire (mais le compteur
non nul!).
PS: Je plaisante !
From | Date | Subject | |
---|---|---|---|
Next Message | Francis Leboutte | 2007-11-19 14:37:33 | Re: taille fichiers BD, RAM, performance |
Previous Message | Guillaume Lelarge | 2007-11-16 16:25:51 | Re: taille fichiers BD, RAM, performance |