Re: Deux tablespaces ?

Puisqu'on revient sur le sujet...

On 12-08-2009, Guillaume Lelarge wrote:
> Le mercredi 12 août 2009 à 18:22:00, William Dode a écrit :
>> On 11-08-2009, Samuel ROZE wrote:
>> > Bonjour,
>> >
>> > Merci à toi et à Marc.
>> >
>> > Ce sont des données simples qui sont appellées individuellements sur
>> > plusieurs jours/semaines. C'est-à-dire que pendant 30 minutes, c'est un
>> > enregistrement qui va être appellé souvent, après, pendant 15 jours il
>> > ne va pas être appellé...
>> >
>> > Or, dès la première récupération, ça doit être éfficace. Memcached vous
>> > semble être une solution ou PostgreSQL fait ça très bien ?
>> >
>> > (je ne connais absolument pas comment PostgreSQL fonctionnes au niveau
>> > de son cache...)
>>
>> Sauf erreur, postgresql n'as pas de query cache (pourquoi au fait ?),
>
> Parce que chaque session voit une image spécifique de la base. Le processus 1
> ne voit pas forcément la même chose que le processus 2. C'est le
> principe du système MVCC.
>
> Même au sein d'un même processus, ce n'est pas forcément intéressant. Une
> requête r1 exécutée au temps t1 ne renverra pas forcément la même chose que la
> même requête exécutée par le même processus au temps t2.

Les processus différents ou non peuvent savoir assez facilement s'il
y a eu une mise à jour sur la base. Au niveau applicatif je gère ce cas,
c'est tellement simple, s'il n'y a eu strictement aucune mises à jour
sur la base (un seul applicatif y a accès) toutes les requêtes sont
mises en cache. A la moindre mise à jour j'efface le cache.

Il me semble que le problème vient surtout du fait qu'une requête
pourrait avoir des effets de bords (appel d'une fonction, d'une date
etc.) et qu'il serait compliqué d'analyser la requête juste pour ça.
Alors qu'au niveau appli, je le décide moi-même suivant la requête.

>
>> donc un cache applicatif est intéressant surtout s'il y a des requêtes
>> lourdes et répétées, sans mises à jour entre.
>
> Même avec des mises à jour, cela peut être intéressant. Mais généralement pour
> des tables de type dictionnaire, dont les données changent, mais peu
> fréquemment. Avec le système du LISTEN/NOTIFY, un client peut être averti de
> certains changements.

Je sais ce qui est la moyenne, mais dans la grande majorité de mes
applis j'ai vraiment beaucoup de requêtes en lecture sans mises à jour
entre. Sur des sites web ça peut même être des mises à jours une seule
fois par semaine.

Ce qui est gênant c'est que d'autres bdd le font, mysql il me semble, ça
peut vachement influencer les benchs...

Par contre, pour moi c'est vraiment simple à gérer au niveau appli donc
ça ne me dérange pas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant