[pgsql-fr-generale] Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL

Bonjour,

philippe.beaudoin@bull.net a écrit :
> [...]
> Comme il n'y avait pas beaucoup de réponse à ton post, j'ai pris mon
> courage à 2 mains et ai fait quelques analyses.

Le manque de réponses me semble dû au fait que personne ne s'est jamais
posé une telle question. Je pense bien que ça a déjà dû traverser
l'esprit de quelqu'un. Mais je ne me rappelle pas avoir lu une
quelconque étude ou mail à ce sujet ici et sur les listes anglophones.

> Pour ne pas avoir à me
> perdre dans les sources de PostgreSQL, j'ai installé WireShark sur mon
> micro et j'ai regardé les messages échangés entre pgAdmin sur mon micro et
> un PostgreSQL sur un serveur Linux.
> WireShark est vraiment génial, puisqu'il sait formater en clair les
> messages du protocole PostgreSQL :-)

Tout comme le fait Etherreal à ma connaissance. Mais j'avoue encore une
fois n'avoir jamais eu la curiosité de regarder ce que cela donnait.

> J'en ai déduit ceci sur la taille des messages échangés (hors couches
> réseau au dessous) :
>
> 1) A l'aller, on a le texte de la requête avec simplement un overhead de 6
> octets.
>
> 2) Au retour, on a un message (découpé éventuellement en plusieurs paquets
> selon la taille) composé de :
> - la description des lignes de la table résultat, dont la longueur en
> octets est égale à :
> 7 + ( 19 * nombre de colonnes) + somme des longueurs des noms des
> colonnes,
> - les lignes de données (voir plus bas),
> - 2 commandes "command completion" et "ready for query" représentant 18
> octets.
> Chaque ligne se compose de :
> - une partie fixe de 7 octets,
> - la liste des colonnes.
> Chaque colonne se compose de :
> - une partie fixe de 4 octets,
> - la valeur de la colonne.
>
> Tout est donc très logique.
>

Oui, en effet.

> 3) Contenu des colonnes :
> Pour les colonnes de type CHAR, on trouve le contenu de la colonne (je n'ai
> pas fait attention aux questions d'encodage qui peuvent j'imagine avoir un
> impact sur la taille physique de chaque caractère). il n'y a pas de
> compression, même pour les blancs à droite.

Exact pour l'encodage, la taille de chaque caractère en dépend. Quant à
la compression, je sais que PostgreSQL stocke parfois en compressant les
données. Pour ce qui est de l'envoi sur le réseau, je n'en sais rien du
tout.

> Pour les colonnes de type VARCHAR, on trouve évidemment la longueur réelle
> du contenu de la colonne et non sa longueur maximale.

Sa longueur maximale se trouve déjà dans la description des colonnes
envoyée au message précédent, non ?

> Pour les colonnes BYTEA, les octets "non imprimables" sont représentés par
> leur séquence d'escape (\nnn).
> Pour les colonnes numériques, la donnée est représentée sous forme de texte
> de longueur variable, c'est à dire la suite des chiffres nécessaires à la
> représentation du nombre.
>

Je suppose que, quand vous parlez de colonnes numériques, vous entendez
le type NUMERIC ? et pas les types int4, float, etc. ? si vous ne parlez
que du types NUMERIC, ça ne m'étonne pas, c'est déjà pas stocké comme un
entier/flottant.

> 4) Les requêtes retournant une ligne et celles retournant plusieurs lignes
> semblent avoir la même structure, quelle que soit le nombre de colonnes.
>
> Voici donc ma compréhension de la structure des messages. Elle est
> peut-être approximative mais ça peut aider. Quelqu'un a peut-être des
> précisions ?
>

En dehors de ce que je viens déjà de dire, non :)

> J'imagine que le dialogue entre pgAdmin et PostgreSQL que j'ai observé est
> le même que celui des autres clients et drivers disponibles. Quelqu'un
> peut-il me confirmer ?
>

Oui dans le sens où pgAdmin s'appuie sur la libpq (la bibliothèque C
d'accès au serveur PostgreSQL), donc tout outil basé sur la libpq fera
de même.

> Pour comprendre pourquoi Oracle qui est un peu moins bon sur 1 ligne
> devient meilleur sur plusieurs lignes, il faudrait faire ce même exercice
> avec Oracle.
> A moins que quelqu'un ait une déjà une idée sur la question...
>

Nope, ma connaissance d'Oracle est pratiquement nulle.

Merci pour ces infos. Même si ce n'est pas particulièrement nouveau,
c'est très intéressant à lire.

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

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale