Re: Deux tablespaces ?

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.

+--On 11 août 2009 17:29:35 +0200 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>
wrote:
| Est-ce possible ? Ou un système similaire ?

Je dirais que je mettrais plutôt beaucoup de RAM dans la machine et que je
laisserai postgresql en manger une énorme partie et l'OS utiliser le reste
pour le cache disque.

--
Mathieu Arnold

Et moi je dirais qu'il me faut 50MB uniquement dans la mémoire RAM et
que la partition est limité à cette taille.

Le mardi 11 août 2009 à 17:35 +0200, Mathieu Arnold a écrit :
> +--On 11 août 2009 17:29:35 +0200 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>
> wrote:
> | Est-ce possible ? Ou un système similaire ?
>
> Je dirais que je mettrais plutôt beaucoup de RAM dans la machine et que je
> laisserai postgresql en manger une énorme partie et l'OS utiliser le reste
> pour le cache disque.
>

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.
>
>

Je présume que le message précédent suggérait simplement de laisser posgresql
faire. Si la table est réellement utilisée tout le temps, elle sera en cache.
C'est plus simple que de la mettre dans un ramdisk, et plus robuste (on reste
dans le cadre d'un fonctionnement normal).

Sinon si il s'agit vraiment de mettre des données précises en cache, la
solution se trouve peut-être hors de la base de données ? (memcached ou affilié)

Le Tuesday 11 August 2009 17:38:46, Samuel ROZE a écrit :
> Et moi je dirais qu'il me faut 50MB uniquement dans la mémoire RAM et
> que la partition est limité à cette taille.
>
> Le mardi 11 août 2009 à 17:35 +0200, Mathieu Arnold a écrit :
> > +--On 11 août 2009 17:29:35 +0200 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>
> >
> > wrote:
> > | Est-ce possible ? Ou un système similaire ?
> >
> > Je dirais que je mettrais plutôt beaucoup de RAM dans la machine et que
> > je laisserai postgresql en manger une énorme partie et l'OS utiliser le
> > reste pour le cache disque.

Samuel ROZE 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.
>
>

il fut un temps où je m'étais écrit un petit gestionnaire de cache qui
gérait en mémoire les requêtes SQL et les retours de Postgres et tant
que la table Postgres n'était pas mis à jour (en update ou delete) et
que la requête était identique renvoyait le contenu de la requête
mémorisée dans un tableau en mémoire. Le gros avantage, c'est que
l'ayant interfacé avec pgpool, c'était transparent pour l'applicatif et
pour ces fainéants de développeurs qui ne voulaient pas toucher à leur
code et je dois dire que sur les incessants (:-( ) SELECT COUNT(*), ça
faisait des merveilles :-)
ceci dit, il auraient pu gérer le tout avec memcached mais projet à la
bourre, etc, etc
je l'avais proposé aux dev postgresql mais retour dans mes 22 car
purement applicatif (donc gérable par memcached) et pas bdd :-(

--
Jean-Max Reymond
CKR Solutions Open Source http://www.ckr-solutions.com

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.
> >
> >
>

+--On 11 août 2009 17:38:46 +0200 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>
wrote:
| Et moi je dirais qu'il me faut 50MB uniquement dans la mémoire RAM et
| que la partition est limité à cette taille.
|
| Le mardi 11 août 2009 à 17:35 +0200, Mathieu Arnold a écrit :
|> +--On 11 août 2009 17:29:35 +0200 Samuel ROZE <samuel(dot)roze(at)aliceadsl(dot)fr>
|> wrote:
|> | Est-ce possible ? Ou un système similaire ?
|>
|> Je dirais que je mettrais plutôt beaucoup de RAM dans la machine et que
|> je laisserai postgresql en manger une énorme partie et l'OS utiliser le
|> reste pour le cache disque.

Ben, alors, si la table fait 50Mo, si la machine a un peu de ram, entre 1
et 2Go, ta table sera déjà dans le cache disque, et tu n'a pas a te
préoccuper du problème de tablespace plus là au redémarrage.

--
Mathieu Arnold

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.

Bonjour,

Le 11 août 09 à 18:30, Samuel ROZE a écrit :
> 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...)

Ne _jamais_ optimiser _avant_ d'avoir des problèmes de performance, ou
bien en anglais dans le texte :

In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements",
he wrote: "Programmers waste enormous amounts of time thinking about,
or worrying about, the speed of noncritical parts of their programs,
and these attempts at efficiency actually have a strong negative
impact when debugging and maintenance are considered. We should forget
about small efficiencies, say about 97% of the time: premature
optimization is the root of all evil."

Or ta dernière intervention me fait penser que tu ne sais pas encore
si tu vas être confronté à un soucis de performance, et pas non plus
si celui là sera lié à la manière de mettre les données en cache.

Il est temps de faire des tests de performances (je recommandes Tsung)
sur ton application (ou son prototype, mais avec des quantités de
données représentatives) et si nécessaire un peu de profiling. Ensuite
on parlera peut être de comportement du cache système et linux.

Bonne soirée,
--
dim

Le mardi 11 août 2009, Dimitri Fontaine a écrit :
> Bonjour,
>
> Le 11 août 09 à 18:30, Samuel ROZE a écrit :
> > 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...)
>
> Ne _jamais_ optimiser _avant_ d'avoir des problèmes de performance, ou
> bien en anglais dans le texte :
>
> In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements",
> he wrote: "Programmers waste enormous amounts of time thinking about,
> or worrying about, the speed of noncritical parts of their programs,
> and these attempts at efficiency actually have a strong negative
> impact when debugging and maintenance are considered. We should forget
> about small efficiencies, say about 97% of the time: premature
> optimization is the root of all evil."
>
> Or ta dernière intervention me fait penser que tu ne sais pas encore
> si tu vas être confronté à un soucis de performance, et pas non plus
> si celui là sera lié à la manière de mettre les données en cache.
>
> Il est temps de faire des tests de performances (je recommandes Tsung)
> sur ton application (ou son prototype, mais avec des quantités de
> données représentatives) et si nécessaire un peu de profiling. Ensuite
> on parlera peut être de comportement du cache système et linux.

j'aurais pas mieux dit :)

>
> Bonne soirée,

----
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

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 ?),
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. Et memcached est utile
à son tour si en plus de cette condition plusieurs applis distinctes,
voir sur des machines différentes, accèdent à la base en même temps.

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

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.

> 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.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On Wed, Aug 12, 2009 at 06:58:01PM +0200,
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote
a message of 45 lines which said:

> > Sauf erreur, postgresql n'as pas de query cache (pourquoi au fait ?),
>
> Parce que chaque session voit une image spécifique de la base.

Ce qui ne veut pas dire que les caches n'existent pas lorsqu'on crée
une nouvelle transaction à chaque fois, puisqu'il y a ceux du
système. Ici, sur Debian/Linux, avec l'option -e qui fait une nouvelle
connexion à chaque requête, notez la durée bien plus longue de la
première requête :

% echoping -n 8 -m postgresql localhost -c dbname=dnsmezzo2 -e \
'SELECT count(*) FROM DNS_packets WHERE file=57'
Elapsed time: 119.581666 seconds
Elapsed time: 0.965749 seconds
Elapsed time: 0.995577 seconds
Elapsed time: 0.936664 seconds
Elapsed time: 0.983532 seconds
Elapsed time: 0.988601 seconds
Elapsed time: 0.986463 seconds
Elapsed time: 0.991618 seconds
---
Minimum time: 0.936664 seconds (273 bytes per sec.)
Maximum time: 119.581666 seconds (2 bytes per sec.)
Average time: 15.803733 seconds (16 bytes per sec.)
Standard deviation: 39.224375
Median time: 0.987532 seconds (259 bytes per sec.)

Le mardi 25 août 2009 à 10:46:59, Stephane Bortzmeyer a écrit :
> On Wed, Aug 12, 2009 at 06:58:01PM +0200,
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote
>
> a message of 45 lines which said:
> > > Sauf erreur, postgresql n'as pas de query cache (pourquoi au fait ?),
> >
> > Parce que chaque session voit une image spécifique de la base.
>
> Ce qui ne veut pas dire que les caches n'existent pas lorsqu'on crée
> une nouvelle transaction à chaque fois, puisqu'il y a ceux du
> système. Ici, sur Debian/Linux, avec l'option -e qui fait une nouvelle
> connexion à chaque requête, notez la durée bien plus longue de la
> première requête :
>
> % echoping -n 8 -m postgresql localhost -c dbname=dnsmezzo2 -e \
> 'SELECT count(*) FROM DNS_packets WHERE file=57'
> Elapsed time: 119.581666 seconds
> Elapsed time: 0.965749 seconds
> Elapsed time: 0.995577 seconds
> Elapsed time: 0.936664 seconds
> Elapsed time: 0.983532 seconds
> Elapsed time: 0.988601 seconds
> Elapsed time: 0.986463 seconds
> Elapsed time: 0.991618 seconds
> ---
> Minimum time: 0.936664 seconds (273 bytes per sec.)
> Maximum time: 119.581666 seconds (2 bytes per sec.)
> Average time: 15.803733 seconds (16 bytes per sec.)
> Standard deviation: 39.224375
> Median time: 0.987532 seconds (259 bytes per sec.)

Ce n'est pas un cache de requêtes, c'est un cache de fichiers (au niveau
Linux, comme au niveau PostgreSQL).

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On Tue, Aug 25, 2009 at 10:56:08AM +0200,
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote
a message of 40 lines which said:

> Ce n'est pas un cache de requêtes, c'est un cache de fichiers (au
> niveau Linux, comme au niveau PostgreSQL).

Le résultat est le même :-) Et, si on veut pinailler, c'est sans doute
surtout un cache de blocs :-)

Stephane Bortzmeyer a écrit :
> On Tue, Aug 25, 2009 at 10:56:08AM +0200,
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote
> a message of 40 lines which said:
>
>> Ce n'est pas un cache de requêtes, c'est un cache de fichiers (au
>> niveau Linux, comme au niveau PostgreSQL).
>
> Le résultat est le même :-) Et, si on veut pinailler, c'est sans doute
> surtout un cache de blocs :-)
>
le résultat n'est pas le même car si tu as un count(*) sur une table de
24 Go, tu as plus de chance d'avoir dans ton cache de requête le
résultat de ton count(*) que celui des 24 Go de la table dans ton cache
de fichiers.

--
Jean-Max Reymond
CKR Solutions Open Source http://www.ckr-solutions.com

On Tue, Aug 25, 2009 at 11:04:49AM +0200,
Jean-Max Reymond <jmreymond(at)gmail(dot)com> wrote
a message of 19 lines which said:

> le résultat n'est pas le même car si tu as un count(*) sur une table
> de 24 Go, tu as plus de chance d'avoir dans ton cache de requête le
> résultat de ton count(*) que celui des 24 Go de la table dans ton
> cache de fichiers.

Oui, je comprends (au fait, la table de mes tests faisait justement 24
Go pile, c'est amusant mais le WHERE réduisait la taille
considérablement). Ceci dit, lorsqu'on fait un COUNT(*), je ne pense
pas que PostgreSQL lise depuis le disque la totalité des données,
non ? Cela serait inutile.

(On dévie du sujet original, là, je suis d'accord avec la conclusion
générale, qu'il faut acheter de la RAM et laisser PostgreSQL et Linux
se débrouiller, mais je voulais juste améliorer ma compréhension du
fonctionnement du SGBD.)

Le mardi 25 août 2009 à 11:04:49, Jean-Max Reymond a écrit :
> Stephane Bortzmeyer a écrit :
> > On Tue, Aug 25, 2009 at 10:56:08AM +0200,
> > Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote
> >
> > a message of 40 lines which said:
> >> Ce n'est pas un cache de requêtes, c'est un cache de fichiers (au
> >> niveau Linux, comme au niveau PostgreSQL).
> >
> > Le résultat est le même :-) Et, si on veut pinailler, c'est sans doute
> > surtout un cache de blocs :-)
>
> le résultat n'est pas le même car si tu as un count(*) sur une table de
> 24 Go, tu as plus de chance d'avoir dans ton cache de requête le
> résultat de ton count(*) que celui des 24 Go de la table dans ton cache
> de fichiers.

Sans compter qu'il suffit de lire le résultat dans un cas, alors que dans
l'autre il faut tout recalculer. Donc, même dans le cas où tout tient dans le
cache, il serait plus rapide d'avoir le résultat via un cache de requêtes que
via un cache de blocs (car c'est bien des blocs pour être précis :) ).

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Le mardi 25 août 2009 à 11:14:37, Stephane Bortzmeyer a écrit :
> On Tue, Aug 25, 2009 at 11:04:49AM +0200,
> Jean-Max Reymond <jmreymond(at)gmail(dot)com> wrote
>
> a message of 19 lines which said:
> > le résultat n'est pas le même car si tu as un count(*) sur une table
> > de 24 Go, tu as plus de chance d'avoir dans ton cache de requête le
> > résultat de ton count(*) que celui des 24 Go de la table dans ton
> > cache de fichiers.
>
> Oui, je comprends (au fait, la table de mes tests faisait justement 24
> Go pile, c'est amusant mais le WHERE réduisait la taille
> considérablement). Ceci dit, lorsqu'on fait un COUNT(*), je ne pense
> pas que PostgreSQL lise depuis le disque la totalité des données,
> non ? Cela serait inutile.
>

Il lit l'intégralité de la table, ce qui sous-entend des lectures du cache
pour les blocs en cache et des lectures du disque pour les autres.

> (On dévie du sujet original, là, je suis d'accord avec la conclusion
> générale, qu'il faut acheter de la RAM et laisser PostgreSQL et Linux
> se débrouiller, mais je voulais juste améliorer ma compréhension du
> fonctionnement du SGBD.)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

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