Skip site navigation (1) Skip section navigation (2)

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

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: philippe(dot)beaudoin(at)bull(dot)net
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL
Date: 2008-07-19 08:27:10
Message-ID: 4881A55E.8010602@lelarge.info (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Bonjour,

philippe(dot)beaudoin(at)bull(dot)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

In response to

Responses

pgsql-fr-generale by date

Next:From: Jonathan BalletDate: 2008-07-19 09:21:41
Subject: Re: Re: Réf. : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL
Previous:From: philippe.beaudoinDate: 2008-07-19 07:51:45
Subject: Réf. : Probleme Traffic réseau PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group