Re: Deux tablespaces ?

Si la donnée n'est pas appelée pendant 15 jours, elle a de bonnes chances de
sortir du cache. Maintenant, qu'appelle t'on efficace ? La plupart du temps,
aller chercher un enregistrement qui n'est pas dans le cache, ça va entrainer
2 ou 3 entrées/sorties (trouver l'entrée dans l'index puis aller dans le bon
bloc de la table). Donc probablement dans les 10ms sur un bon disque…

50Mo c'est vraiment une très petite table…

Le Tuesday 11 August 2009 18:30:36, Samuel ROZE a écrit :
> 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...)
>
> Cordialement,
> Samuel.
>
> Le mardi 11 août 2009 à 17:50 +0200, Jean-Samuel Reynaud a écrit :
> > Bonjour,
> >
> > À ma connaissance, il n'existe pas de système faisant cela. Je serai
> > d'ailleurs très surpris de le découvrir un jour dans la mesure où un tel
> > système serait illogique dans le fonctionnement de Postgresql (comme de
> > toute les bases de données d'ailleurs) qui est de garantir au maximum la
> > non-perte de données... (Je pense en fait que tu cherches en réalité un
> > mécanisme de mise en cache/ram automatique des tables .)
> >
> > Dans la mise en place de ton mécanisme, Postgresql râle de ne pas
> > trouver la table là où elle était attendue et tu as une erreur (normale)
> > mais qui, en général, est très grave (sauf que toi tu l'as provoquée
> > volontairement). Je pense que tu vas au devant de gros problèmes à
> > détourner Postgresql de cette manière là (à mon avis tout du moins). Je
> > t'encourage à utiliser un autre mécanisme. Si tu es sous linux, le cache
> > OS est très agressif naturellement et il peut être configuré finement.
> > Je pense que s'appuyer sur ce cache me semble très largement suffisant.
> > En gros tu n'as qu'a 'pré-charger' les tables dans le cache de l'OS si tu
> > veux vraiment sur ça soit en RAM dès le démarrage (avec simplement un
> > select * des tables par exemple mais il doit exister d'autre solutions).
> > Les autres mécanismes de cache en ram sont plus des gestions
> > applicatives de ton problème (avec memcache par exemple)
> >
> > Voilà,
> > Le Tue, 11 Aug 2009 17:29:35 +0200,
> >
> > Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr> a écrit :
> > > Bonjour à tous,
> > >
> > > Dans un besoin de performance exellentes, je souhaite mettre en RAM
> > > certaines tables de ma base de données (pas lourdes).
> > >
> > > Je vais donc utiliser les tablespace. Or, les performances doivent être
> > > performantes pour la lecture, et non l'écriture. Est-ce possible
> > > d'avoir deux tablespaces pour que si mon serveur crash, j'ai n'ai pas
> > > un beau:
> > >
> > > ERREUR: n'a pas pu ouvrir la relation 24576/16399/24668 : Aucun
> > > fichier ou répertoire de ce type
> > >
> > > A la lecture, il lit dans la tablespace ram, s'il ne le trouve pas,
> > > dans l'autre. A l'écriture, c'est dans les deux...
> > >
> > > Est-ce possible ? Ou un système similaire ?
> > >
> > > Samuel.