Derni�re mise � jour : vendredi 14 novembre 2004 16:32:47
Mainteneur actuel : Bruce Momjian (pgman@candle.pha.pa.us)
La plus r�cente version de ce document est disponible sur http://www.PostgreSQL.org/docs/faqs/FAQ.html.
Les questions sp�cifiques � la plateforme sont r�pondues sur http://www.PostgreSQL.org/docs/index.html.
IN sont-elles si lentes ?PostgreSQL se prononce Post-Gres-Q-L. Un fichier audio est disponible sur http://www.postgresql.org/postgresql.mp3 pour ceux souhaitant entendre la prononciation.
PostgreSQL est une am�lioration du syst�me de gestion de bases de donn�es POSTGRES (et est toujours quelque fois appel� "Postgres"), un prototype de recherche de SGBD de prochaine g�n�ration. PostgreSQL garde le puissant mod�le de donn�es et les types de donn�es riches de POSTGRES, mais remplace le langage de requ�tes PostQuel par un sous-ensemble �tendu de SQL. PostgreSQL est gratuit et les sources complets sont disponibles.
PostgreSQL est �crit par une �quipe de d�veloppeurs qui sont tous inscrits � la liste de diffusion de d�veloppement de PostgreSQL. Le coordinateur actuel est Marc G. Fournier (scrappy@PostgreSQL.org et voir la section 1.6 pour contacter les d�veloppeurs). Cette �quipe est responsable de tout le d�veloppement de PostgreSQL. C'est un projet soutenu par une communaut� sans �tre contr�l� par une soci�t�. Pour y contribuer, voir la FAQ des d�veloppeurs sur http://www.postgresql.org/docs/faqs/FAQ_DEV.html.
Les auteurs de PostgreSQL 1.01 �taient Andrew Yu et Jolly Chen. Beaucoup d'autres personnes ont contribu� au portage, aux tests, au d�boguage et � l'am�lioration du code. Le code de Postgres original, duquel PostgreSQL est d�riv�, �tait le fruit de l'effort de nombreux �tudiants dipl�m�s et non dipl�m�s, et de programmeurs travaillant sous la direction du Professeur Michael Stonebraker � l'universit� de Californie, Berkeley.
Le nom original du logiciel � Berkeley �tait Postgres. Quand le SQL fut ajout� en 1995, le nom a d� �tre chang� en Postgres95. Fin 1996, le nom fut chang� en PostgreSQL.
PostgreSQL est distribu� sous la licence suivante :
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group Portions Copyright (c) 1994-6 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
La licence ci-dessus est la licence BSD, une licence open-source classique.
En g�n�ral, tout environnement compatible Unix moderne devrait pouvoir faire fonctionner PostgreSQL. Les environnements qui ont �t� test�s explicitement sont list�s dans les instructions d'installation.
� partir de la version 8.0, PostgreSQL fonctionne nativement sur les syst�mes d'exploitation Microsoft Windows � base NT comme Win2000, WinXP et Win2003. Un installeur est disponible sur http://pgfoundry.org/projects/pginstaller.
Il existe aussi un port sur Novell Netware sur http://forge.novell.com.
Le site FTP anonyme principal de PostgreSQL est ftp://ftp.PostgreSQL.org/pub. Pour les sites miroirs, voir notre site web principal.
La liste de diffusion principale est pgsql-general@PostgreSQL.org. Elle est disponible pour discuter de sujets en rapport avec PostgreSQL. Pour s'y inscrire, il faut envoyer un courriel avec les lignes suivantes dans le corps du message (pas dans la ligne du sujet) :
subscribe
end
� pgsql-general-request@PostgreSQL.org.
Il existe aussi un recueil de la liste. Pour s'y inscrire, envoyez un courriel � pgsql-general-digest-request@PostgreSQL.org avec dans le corps :
subscribe
end
Les recueils sont envoy�s aux membres de cette liste d�s que la
liste principale a re�u 30 Ko de messages.
Une liste de diffusion de bogues est disponible. Pour s'y inscrire, envoyer un courriel � pgsql-bugs-request@PostgreSQL.org avec dans le corps :
subscribe
end
Une liste de diffusion pour les d�veloppeurs est aussi disponible. Pour s'y
inscrire, envoyez un courriel � pgsql-hackers-request@PostgreSQL.org
avec dans le corps :
subscribe
end
Vous pouvez trouver d'autres listes et informations sur PostgreSQL sur le site web de PostgreSQL :
Il y a aussi un canal IRC sur Freenode et EFNet, le canal
#PostgreSQL. Vous pouvez utiliser la commande Unix
irc -c '#PostgreSQL' "$USER" irc.phoenix.net ou
irc -c '#PostgreSQL' "$USER" irc.freenode.net.
Une liste de soci�t�s pouvant fournir un support commercial est disponible sur http://techdocs.postgresql.org/companies.php.
La derni�re version de PostgreSQL est la version 7.4.5.
Nous projetons de sortir une version majeure tous les six � huit mois.
Plusieurs manuels, pages de manuel ainsi que des petits exemples de test sont inclus dans la distribution. Voir le r�pertoire /doc. Vous pouvez aussi acc�der aux manuels en ligne sur http://www.PostgreSQL.org/docs.
Deux livres sur PostgreSQL sont disponibles en ligne sur http://www.PostgreSQL.org/docs/awbook.html et http://www.commandprompt.com/ppbook/. Il y a une liste de livres sur PostgreSQL pouvant �tre achet�s sur http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Il y a aussi une collection d'articles techniques sur PostgreSQL sur http://techdocs.PostgreSQL.org/.
psql poss�de des commandes \d pratiques montrant des informations sur les types, op�rateurs, fonctions, aggr�gats, etc.
Notre site web contient encore plus de documentations.
PostgreSQL supporte un sous-ensemble �tendu de SQL-92. Voir notre liste TODO pour les bogues connus, les fonctionnalit�s manquantes et les plans pour le futur.
Le livre PostgreSQL sur http://www.PostgreSQL.org/docs/awbook.html enseigne le SQL. Il existe un autre livre PostgreSQL sur http://www.commandprompt.com/ppbook. Il existe de bons tutoriels sur http://www.intermedia.net/support/sql/sqltut.shtm, http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM et http://sqlcourse.com.
Un autre (en anglais uniquement) "Teach Yourself SQL in 21 Days, Second Edition" se trouve sur http://members.tripod.com/er4ebus/sql/index.htm
Nombre de nos utilisateurs aiment The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. D'autres aiment The Complete Reference SQL, Groff et al., McGraw-Hill.
Oui, nous manipulons facilement les dates apr�s et avant l'an 2000.
Tout d'abord, t�l�chargez les derniers sources et lisez la documentation pour les d�veloppeurs sur notre site web ou bien dans la distribution. Ensuite, inscrivez-vous aux listes de diffusion pgsql-hackers et pgsql-patches. Et pour finir, soumettez des correctifs de grande qualit� sur pgsql-patches.
Environ une douzaine de personnes ont des droits de modification sur l'archive CVS de PostgreSQL. Ils ont chacun soumis tellement de correctifs de qualit� qu'il �tait devenu impossible aux d�veloppeurs de tenir la cadence et nous avions confiance dans le qualit� des correctifs qu'ils soumettaient.
Merci de visiter la page PostgreSQL BugTool sur http://www.PostgreSQL.org/bugs/bugs.php, qui donne des indications sur la fa�on de soumettre un rapport de bogue.
De m�me, v�rifiez notre site ftp ftp://ftp.PostgreSQL.org/pub pour voir s'il existe une version PostgreSQL plus r�cente ou des correctifs.
Il y a plusieurs mani�res de mesurer un logiciel : les fonctionnalit�s, les performances, la fiabilit�, le support, et le prix.
PostgreSQL poss�de une infrastructure de premi�re classe depuis le d�but en 1996. Ceci gr�ce � Marc Fournier, qui a cr�� et g�r� cette infrastructure des ann�es durant.
Une infrastructure de qualit� est importante pour un projet open-source. Cela permet d'emp�cher l'�parpillement qui ralentirait beaucoup l'avancement du projet.
Bien s�r, cette infrastructure n'est pas donn�e. Elle requiert un certain nombre de d�penses mensuelles ou ponctuelles. Si vous ou votre soci�t� peut donner de l'argent pour soutenir cet effort, merci de consulter la page web http://store.pgsql.com/shopping/ et de faire une donation.
Bien que la page web mentionne PostgreSQL, Inc, les contributions sont exclusivement utilis�es pour soutenir le projet PostgreSQL et ne soutiennent aucune soci�t� que ce soit. Si vous le pr�f�rez, vous pouvez aussi envoyer un ch�que � l'adresse de contact.
De plus, si vous avez une histoire de succ�s avec PostgreSQL, merci de la soumettre � notre site d'�vang�lisation sur http://advocacy.postgresql.org.
Il y a deux pilotes ODBC disponibles, PsqlODBC et OpenLink ODBC.
Vous pouvez t�l�charger PsqlOBDC depuis http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
OpenLink ODBC peut �tre obtenu depuis http://www.openlinksw.com. Il fonctionne avec leur logiciel client ODBC standard, vous aurez donc PostgreSQL ODBC sur toutes les plateformes client qu'ils supportent (Win, Mac, Unix, VMS).
Ils vendront probablement ce produit aux gens qui recherchent une qualit� de support professionnelle mais une version freeware sera toujours disponible. Merci d'envoyer vos questions � postgres95@openlink.co.uk.
Une bonne introduction aux pages Web adoss�s � une base de donn�es se trouve � http://www.webreview.com
Pour l'int�gration Web, PHP est une excellente interface. Elle se trouve � http://www.php.net.
Pour les cas complexes, beaucoup utilisent l'interface Perl et CGI.pm ou mod_perl.
Oui, il y a plusieurs interfaces graphiques disponibles pour PostgreSQL, dont PgAccess http://www.pgaccess.org), PgAdmin III (http://www.pgadmin.org), RHDB Admin (http://sources.redhat.com/rhdb/ et Rekall ( http://www.thekompany.com/products/rekall/, propri�taire). Il y a aussi PhpPgAdmin ( http://phppgadmin.sourceforge.net/ ), une interface Web pour PostgreSQL.
Voir http://techdocs.postgresql.org/guides/GUITools pour une liste plus d�taill�e.
La plupart des langages de programmation couramment utilis�s ont une interface pour PostgreSQL. V�rifiez la liste des modules de votre langage.
Les interfaces ci-dessous sont incluses dans la distribution :
Interfaces suppl�mentaires disponibles sur http://gborg.postgresql.org dans la section Drivers/Interfaces
Il faut sp�cifier l'option --prefix lors du lancement de configure.
Cela peut �tre d� � une vari�t� de probl�mes mais v�rifiez d'abord que vous avez les extensions System V install�es pour votre noyau. PostgreSQL n�cessite le support noyau pour la m�moire partag�e et les s�maphores.
Soit vous n'avez pas configur� correctement la m�moire partag�e dans votre noyau, soit vous devez augmenter la m�moire partag�e disponible dans le noyau. Le montant exact dont vous avez besoin d�pend de votre architecture et du nombre de tampons et de processus que vous avez configur� pour postmaster. Pour la plupart des syst�mes avec un nombre par d�faut de tampons et de processus, vous aurez besoin d'un minimum d'environ 1 Mo. Voir le chapitre Administration du manuel PostgreSQL pour des informations plus d�taill�es sur la m�moire partag�e et les s�maphores.
Si le message d'erreur est IpcSemaphoreCreate: semget failed (No space left on device) alors votre noyau n'est pas configur� avec suffisamment de s�maphores. PostgreSQL a besoin d'un s�maphore par processus serveur potentiel. Une solution provisoire est de lancer postmaster avec une plus petite limite sur le nombre de processus serveur. Utilisez l'option -N avec un param�tre inf�rieur au choix par d�faut de 32. Une solution permanente est d'augmenter les param�tres SEMMNS et SEMMNI de votre noyau.
Des s�maphores inop�rantes peuvent aussi provoquer des plantages pendant de gros acc�s � la base de donn�es.
Si le message d'erreur est autre chose, vous n'avez peut-�tre pas du tout le support des s�maphores dans votre noyau. Voir le chapitre Administration du manuel PostgreSQL pour des informations plus d�taill�es sur la m�moire partag�e et les s�maphores.
Par d�faut, PostgreSQL autorise seulement les connexions de la machine locale en utilisant les sockets de domaine Unix ou les connexions TCP/IP. D'autres machines ne seront pas capables de se connecter sauf si vous modifiez listen_addresses dans postgresql.conf et activez une authentification bas�e sur l'h�te en modifiant le fichier $PGDATA/pg_hba.conf en accord.
Des index acc�l�reront les requ�tes. La commande EXPLAIN ANALYZE vous permet de voir comment PostgreSQL traite votre requ�te et quels index sont utilis�s.
Si vous faites beaucoup d'insertions (instruction INSERT), envisagez de les faire en une fois en utilisant la commande COPY. Ceci est plus rapide que des commandes INSERTS individuelles. Deuxi�ment, les requ�tes qui ne sont pas dans des blocs de transaction BEGIN WORK/COMMIT sont consid�r�s comme �tant dans leur propre transaction. Envisagez de faire plusieurs instructions dans un seul bloc de transaction. Ceci r�duira la surcharge apport�e par les transactions. Aussi, envisagez d'abandonner et de recr�er des index lors de grosses modifications de donn�es.
Il y a plusieurs options d'optimisations. Vous pouvez d�sactiver fsync() en lan�ant postmaster avec l'option -o -F. Ceci emp�chera les fsync()s d'�crire sur disque apr�s toute transaction.
Vous pouvez utiliser l'option -B de postmaster pour augmenter le nombre de tampons de m�moire partag�e utilis�s par les processus serveurs. Si vous fixez ce param�tre trop haut, postmaster ne se lancera pas car vous avez d�pass� la limite de votre noyau sur la quantit� de m�moire partag�e. Chaque tampon fait 8 Ko et le choix par d�faut est de 64 tampons.
Vous pouvez utiliser l'option serveur -S pour augmenter la quantit� maximale de m�moire utilis�e par les processus serveurs pour des tris temporaires. La valeur de -S est mesur� en kilooctets et le choix par d�faut est de 512 (c'est-�-dire 512 Ko).
Vous pouvez utiliser la commande CLUSTER pour regrouper vos donn�es en tables pour correspondre � un index. Voir la page de manual CLUSTER pour plus de d�tails.
PostgreSQL a plusieurs fonctionalit�s qui permettent de recueillir des informations de statut qui peuvent �tre utile pour des intentions de d�boguage.
D'abord, en lan�ant configure avec l'option --enable-cassert, beaucoup d'assert()s surveillent le serveur et arr�tent le programme quand quelque chose d'inattendu arrive.
Postmaster et postgres ont tous deux plusieurs options de d�boguage de disponible. D'abord, quand vous lancez postmaster, v�rifiez que vous envoyez les sorties standard et d'erreur dans un fichier de traces comme :
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
Ceci va cr�er un fichier server.log dans le r�pertoire racine de PostgreSQL. Ce fichier contient des informations utiles sur les probl�mes ou erreurs rencontr�s par le serveur. Postmaster dispose d'une option -d qui permet de rapporter des informations encore plus d�taill�es d'�tre rapport�es. L'option -d prend un num�ro qui sp�cifie le niveau de d�boguage. Faites attention au fait que des valeurs �l�v�es de niveau de d�boguage g�nerent des fichiers de traces volumineux.
Si postmaster ne tourne pas, vous pouvez lancer le serveur postgres de la ligne de commande et taper votre requ�te SQL directement. Ceci est recommand� seulement pour des fonctions de d�boguage. Notez qu'un retour chariot termine la requ�te, pas un point-virgule. Si vous compilez avec les symboles de d�boguage, vous pouvez utiliser un d�bogueur pour voir ce qui se passe. Parce que le serveur n'a pas �t� lanc� par postmaster, il ne tourne pas dans un environnement identique et les probl�mes d'interaction de verrouillage/serveur ne peuvent �tre dupliqu�s.
Si postmaster est en train de tourner, lancez psql dans une fen�tre puis trouvez le PID du processus postgres utilis� par psql. Utilisez un d�bogueur pour l'attacher au PID postgres. Vous pouvez mettre un point d'arr�t dans le d�bogueur et envoyez des requ�tes de psql. Si vous d�boguez le d�marrage de postgres, vous pouvez mettre PGOPTIONS="-W n", puis lancez psql. Ceci va retarder le d�marrage de n secondes pour que vous puissiez attacher un d�bogueur au processus, fixer des points d'arr�t et continuer la s�quence de d�marrage.
Le programme postgres a les options -s, -A et -t qui peuvent �tre utile pour des mesures de d�boguage et de performance.
Vous pouvez compiler avec les options de performance pour voir quelles fonctions prennent du temps d'ex�cution. Les fichiers de gestion du serveur seront d�pos�s dans le r�pertoire pgsql/data/base/nom_db. Les fichiers de gestion clients seront mis dans le r�pertoire actuel du client. Linux requiert une compilation avec -DLINUX_PROFILE pour une meilleure gestion.
Vous pouvez augmenter la limite de postmaster sur le nombre de processus serveur concurrents qu'il peut lancer.
La limite par d�faut est de 32 processus. Vous pouvez l'augmenter en relan�ant postmaster avec une valeur -N appropri�e ou en modifiant postgresql.conf.
Tenez compte du fait que si vous fixez -N plus grand que 32, vous devez aussi augmenter -B au-dela de sa valeur par d�faut 64 ; -B doit valoir au moins deux fois -N et probablement plus pour une meilleure performance. Pour de grand nombres de processus serveurs vous aurez probablement aussi augmenter plusieurs parametres de configuration du noyau Unix. Les choses a v�rifier incluent la taille maximale des blocs de m�moire partag�e, SHMMAX ; le nombre maximal de s�maphores, SEMMNS et SEMMNI ; le nombre maximal de processus, NPROC ; le nombre maximal de processus par utilisateur, MAXUPRC ; et le nombre maximal de fichiers ouverts, NFILE et NINODE. La raison pour laquelle PostgreSQL a une limite sur le nombre de processus serveurs autoris�s est pour que votre syst�me ne tombe pas � court de ressources.
Ce r�pertoire contient des fichiers temporaires g�n�r�s par le moteur de requ�te. Par exemple, si un tri doit �tre fait pour satisfaire un ORDER BY et que ce tri requiert plus de place que le param�tre -S du serveur n'autorise, alors des fichiers temporaires seront cr��s pour contenir les donn�es n�cessaires.
Les fichiers temporaires sont d'habitude effac�s automatiquement mais peuvent rester si un serveur s'arr�te brutalement pendant un tri. Un arr�t et un red�marrage de postmaster effacera les fichiers dans ces r�pertoires.
L'�quipe PostgreSQL ne fait que des changements mineurs entre des versions mineurs, donc mettre � jour de 7.2 vers 7.2.1 ne n�cessitera pas de sauvegarde et de restauration. Par contre, les sorties majeures (c'est-�-dire de 7.2 vers 7.3) changent souvent le format interne des tables syst�mes et des fichiers de donn�es. Ces modifications sont souvent complexes alors nous ne gardons pas de compatibilit� descendante pour les fichiers de donn�es. Une sauvegarde exportera les donn�es dans un format g�n�rique qui peut ensuite �tre charg� dans le nouveau format interne.
Dans les sorties o� le format sur disque ne change pas, le script pg_upgrade peut �tre utilis� pour mettre � jour sans sauvegarde/restauration. Les notes de sorties pr�cisent si pg_upgrade est disponible pour la sortie.
Comme le mat�riel PC est compatible en grosse partie, les gens ont tendance � croire que tous les mat�riels PC sont de m�me qualit�. Ce n'est pas le cas. La RAM ECC, le SCSI et les cartes-m�re de qualit� sont plus fiables et ont de meilleurs performances qu'un mat�riel moins co�teux. PostgreSQL fonctionnera sur � peu pr�s tout mat�riel mais si la fiabilit� et la performance sont importantes pour vous, il est rus� de bien consid�rer les options mat�rielles. Nos listes de diffusion peuvent �tre utilis�es pour discuter des options mat�riels.
Voir la page DECLARE du manuel pour une description.
Voir la page FETCH du manuel ou utiliser SELECT ... LIMIT....
Il se peut que l'int�gralit� de la requ�te doive �tre �valu�e, m�me si vous voulez seulement les premi�res lignes. Envisagez d'utiliser une requ�te avec une clause ORDER BY. S'il existe un index correspondant � l'ORDER BY, PostgreSQL peut n'�valuer que les premi�res lignes, sinon l'int�gralit� de la requ�te peut �tre �valu�e, jusqu'� g�n�rer les lignes d�sir�es.
Pour faire un SELECT sur une ligne al�atoire :
SELECT colonne
FROM table
ORDER BY random()
LIMIT 1;
Utilisez la commande \dt pour voir les tables dans psql. Pour une liste compl�te de commandes � l'int�rieur de psql, vous pouvez utiliser \?. Autrement, vous pouvez lire le code source de psql dans le fichier pgsql/src/bin/psql/describe.c. Il contient des commandes SQL qui g�n�rent le contenu des commandes anti-slash de psql. Vous pouvez aussi lancer psql avec l'option -E, afin qu'il imprime les requ�tes qu'il utilise pour ex�cuter les commandes que vous lui passez. PostgreSQL fournit aussi une interface d'informations sur le sch�ma compatible avec SQLi que vous pouvez interroger des informations sur la base de donn�es.
La fonction DROP COLUMN a �t� ajout�e dans la version 7.3 avec ALTER TABLE DROP COLUMN. Pour les versions pr�c�dentes, vous pouvez faire :
BEGIN;
LOCK TABLE ancienne_table;
SELECT ... -- s�lectionnez toutes les colonnes sauf celle � supprimer
INTO TABLE nouvelle_table
FROM ancienne_table;
DROP TABLE ancienne_table;
ALTER TABLE nouvelle_table RENAME TO ancienne_table;
COMMIT;
Pour changer le type de donn�es d'une colonne, faites :
BEGIN;
ALTER TABLE table ADD COLUMN nouvelle_colonne nouveau_type_de_donnees;
UPDATE table SET nouvelle_colonne = CAST(ancienne_colonne AS nouveau_type_de_donnees);
ALTER TABLE table DROP COLUMN ancienne_colonne;
COMMIT;
Apr�s, vous pouvez faire VACUUM FULL tab pour r�cup�rer l'espace disque utilis� par les lignes expir�es.
Les limites sont :
Taille maximum pour une base de donn�es illimit�e (il existe des bases de 32 To)
Taille maximum pour une table 32 To
Taille maximum pour une ligne 1,6 To
Taille maximum pour un champ 1 Go
Nombre maximum de lignes dans une table illimit�
Nombre maximum de colonnes dans une table 250-1600, selon le type de colonnes
Nombre maximum d'index sur une table illimit�
Bien s�r, ces valeurs ne sont pas vraiment illimit�e, elles sont limit�es par l'espace disque disponible, ainsi que par l'espace de m�moire et de swap. Les performances peuvent se d�grader si ces valeurs sont inhabituellement grandes.
La taille maximum des tables (32 To) ne n�cessite pas que le syst�me d'exploitation supporte les grands fichiers. Les grandes tables sont stock�es sous forme de fichiers multiples de 1 Go, donc les limites de taille du syst�me de fichier ne sont pas importantes.
La taille maximum des tables et le nombre maximum de colonnes peuvent �tre quadripl�s, si la taille des blocs par d�faut est augment�e � 32 Ko.
Une base de donn�es PostgreSQL peut utiliser jusqu'� cinq fois l'espace n�cessaire pour stocker les donn�es d'un fichier texte.
A titre d'exemple, consid�rez un fichier de 100 000 lignes, comportant un entier et une cha�ne de description sur chaque ligne. Supposons que la cha�ne soit longue en moyenne de 20 octets. Le fichier texte serait de 2,8 Mo. La taille du fichier d'une base de donn�es PostgreSQL peut �tre estim�e � 6,4 Mo :
32 octets: chaque ligne (approximation)
24 octets: un champ 'entier' et un champ 'texte'
+ 4 octets: pointeur vers le tuple sur la page
----------------------------------------
60 octets par ligne
La taille des pages de donn�es dans PostgreSQL est de 8192 octets (8 KO), donc :
8192 octets par page
---------------------- = 136 lignes par page de base de donn�es (arrondi � l'entier inf�rieur)
60 octets par ligne
100000 lignes de donn�es
------------------------- = 735 pages de base de donn�es (arrondi � l'entier sup�rieur)
128 lignes par page
735 pages de base de donn�es * 8192 octets par page = 6 021 120 octets (6,4 Mo)
Les index utilisent moins d'espace, mais ils contiennent les donn�es index�es, ils peuvent donc �galement �tre grands.
Les NULL sont stock�s sous forme de bitmap, aussi utilisent-ils tr�s peu d'espace.
psql dispose de plusieurs commandes commen�ant par un anti-slash pour retrouver ces informations. Utilisez \? pour les conna�tre. Il existe aussi des tables syst�mes, qui commencent par pg_ et qui les d�crivent �galement. Aussi, psql -l liste toutes les bases de donn�es.
Essayez �galement le fichier pgsql/src/tutorial/syscat.source. Il illustre un grand nombre de commandes SELECT n�cessaires pour r�cup�rer l'information des tables syst�me de la base de donn�es.
Les index ne sont pas automatiquement utilis�s par chaque requ�te. Ils sont utilis�s uniquement si la table est plus grande qu'une certaine taille, et si la requ�te s�lectionne seulement un faible pourcentage des lignes de la table. Ceci est d� au fait qu'un acc�s disque al�atoire caus� par un parcours d'index peut �tre plus lent qu'une simple lecture de la table, ou parcours s�quentiel
Pour d�terminer si un index devrait �tre utilis�, PostgreSQL a besoin des statistiques de la table. Ces statistiques sont collect�es en lan�ant VACUUM ANALYZE ou simplement ANALYZE. Avec les statistiques, l'optimiseur sait combien de lignes se trouvent dans la table et peut mieux d�terminer s'il faut utiliser l'index. Les statistiques sont �galement utiles pour d�terminer l'ordre optimal des op�rations de jointure. La collecte des statistiques devrait �tre effectu�e r�guli�rement lorsque le contenu de la table change.
Les index ne sont normalement pas utilis�s pour les clauses ORDER BY ou pour les jointures. Un parcours s�quentiel suivi d'un tri explicite est habituellement plus rapide qu'un parcours d'index pour une table importante. Toutefois, LIMIT combin� avec ORDER BY utilisera souvent un index parce que seulement une petite partie de la table est renvoy�e. En fait, bien que MAX() et MIN() n'utilisent pas les index, il est possible de retrouver ces valeurs en utilisant un index avec ORDER BY et LIMIT :
SELECT colonne
FROM table
ORDER BY colonne [ DESC ]
LIMIT 1;
Si vous pensez que l'optimiseur choisit par erreur un parcours sequentiel,
utilisez SET enable_seqscan TO 'off' et
lancez des tests pour voir si le parcours d'index est effectivement plus rapide.
Lorsque vous utilisez des caract�res joker tels que LIKE ou ~, les index peuvent seulement �tre utilis�s dans certaines circonstances :
Dans les versions ant�rieures � la 8.0, les indexs ne peuvent souvent pas �tre utilis�s sauf si les types de donn�es correspondent exactement au type de la colonne de l'index. Ceci est particuli�rement vrai pour les index de colonnes de type int2, int8 et numeric.
Voir la page EXPLAIN du manuel.
Un index R-tree est utilis� pour l'indexation des donn�es spatiales. Un index de hachage ne permet pas les recherches par plage. Un index B-tree peut seulement faire des recherches sur une dimension. Les index R-tree peuvent traiter des donn�es multi-dimensionnelles. Par exemple, si un index R-tree peut �tre construit sur un attribut de type point, le syst�me peut plus efficacement g�rer les requ�tes du type "S�lection de tous les points d'un rectangle".
L'article de r�f�rence qui d�crit le syst�me R-tree original est :
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
Vous pouvez �galement trouver ce papier dans le livre de Stonebraker "Readings in Database Systems".
Les index R-tree int�gr�s peuvent prendre en charge les polyg�nes et les bo�tes. En th�orie, les R-trees peuvent �tre �tendus � un plus grand nombre de dimensions. En pratique, l'extension des R-trees requiert pas mal de travail et nous n'avons pour le moment aucune documentation sur la fa�on de proc�der.
Le module GEQO (acronyme de GEnetic Query Optimizer) acc�l�re l'optimisation des requ�tes lors de jointures de nombreuses tables par un algorithme g�n�tique (GA). Il permet la gestion des grosses requ�tes de jointures en utilisant une recherche non exhaustive.
L'op�rateur ~ r�alise des recherches d'expressions rationnelles et ~* le fait sans tenir compte de la casse. La variante de LIKE non sensible � la casse est ILIKE.
Des comparaisons d'�galit� non sensibles � la casse sont habituellement exprim�es de cette fa�on :
SELECT *
FROM table
WHERE lower(colonne) = 'abc';
Ceci n'utilisera pas un index standard. N�anmoins, si vous cr�ez un index fonctionnel, celui-ci sera utilis� :
CREATE INDEX tableindex ON table (lower(colonne));
Il vous suffit de tester la colonne avec IS NULL ou IS NOT NULL.
Type Nom interne Notes
--------------------------------------------------
VARCHAR(n) varchar n sp�cifie la taille maximum, sans remplissage
CHAR(n) bpchar des espaces sont ajout�s pour obtenir la
longueur fixe sp�cifi�e
TEXT text pas de limite sup�rieure pour la taille
BYTEA bytea tableau d'octets (accepte les octets nuls)
"char" char un caract�re
Vous verrez le nom interne en examinant les catalogues syst�me et dans quelques messages d'erreur.
Les quatres premiers types du dessus sont des types "varlena" (c'est-�-dire que les quatre premiers octets correspondent � la taille, suivi des donn�es). Donc, l'espace r�ellement utilis� est l�g�rement plus grand que la taille d�clar�e. N�anmoins, ces types de donn�es sont aussi sujet � la compression ou � un enregistrement en dehors de la table avec TOAST, donc l'espace occup� sur disque pourrait aussi �tre moindre que ce qu'on pourrait attendre.
VARCHAR(n) est bien mieux pour enregistrer des cha�nes de longueurs variables tout en limitant la taille de cette cha�ne. TEXT est utile pour les cha�nes de longueur illimit�e, avec malgr� tout un maximum de 1 Go.
CHAR(n) est int�ressant pour stocker des cha�nes de taille identique. CHAR(n) compl�te avec des espaces pour arriver � la taille sp�cifi�e alors que VARCHAR(n) n'enregistre que les caract�res donn�s. BYTEA sert � stocker des donn�es binaires, particuli�rement les donn�es incluant des octets NULL. Tous les types d�crits ici ont des performances similaires.
PostgreSQL supporte un type de donn�es SERIAL. Il cr�e automatiquement une s�quence. Par exemple, ceci :
CREATE TABLE personne (
id SERIAL,
nom TEXT
);
est automatiquement traduit en ceci :
CREATE SEQUENCE personne_id_seq;
CREATE TABLE personne (
id INT4 NOT NULL DEFAULT nextval('personne_id_seq'),
nom TEXT
);
Voir la page man de create_sequence pour plus d'informations
sur les s�quences. Vous pouvez aussi utiliser le champ OID de chaque
ligne comme valeur unique. N�anmoins, si vous avez besoin de sauvegarder
puis recharger la base de donn�es, vous devrez utiliser l'option
-o ou l'option COPY WITH OIDS de
pg_dump pour conserver les OIDs.
Une approche pour r�cup�rer la prochaine valeur SERIAL � partir de l'objet s�quence est d'utiliser la fonction nextval() avant l'insertion et de l'ins�rer ensuite explicitement. En utilisant la table d'exemple de la section 4.15.1, un exemple dans un pseudo-langage ressemblerait � ceci :
nouvelle_id = execute("SELECT nextval('personne_id_seq')");
execute("INSERT INTO personne (id, nom) VALUES (nouvelle_id, 'Blaise Pascal')");
Vous pourriez ensuite utiliser la nouvelle valeur stock�e dans
nouvelle_id avec d'autres requ�tes (c'est-�-dire en tant que
cl� �trang�re de la table personne). Notez que le nom de la
SEQUENCE automatiquement cr��e sera
<table>_<colonneserial>_seq, o�
table et colonneserial sont les noms respectifs de votre table
et de votre colonne SERIAL.
Autrement, vous pouvez r�cup�rer la valeur SERIAL affect�e avec la fonction currval() apr�s qu'elle ait �t� ins�r�e par d�faut, c'est-�-dire,
execute("INSERT INTO personne (nom) VALUES ('Blaise Pascal')");
nouvelle_id = execute("SELECT currval('personne_id_seq')");
Enfin, vous pouvez utiliser l'OID renvoy�
par l'instruction INSERT pour r�cup�rer la valeur par d�faut
bien que cela soit l'appoche la moins portable et la valeur de l'OID se
r�initialisera aux environs de quatre milliards. En Perl, avec DBI et le
module DBD:Pg d'Edmund Mergl, l'ancienne valeur est disponible via
$sth->{pg_oid_status} apr�s un $sth->execute().
Non. currval() renvoie la valeur actuelle affect�e par votre processus, et non pas par tous les utilisateurs.
Pour am�liorer les acc�s concurrents, les valeurs de s�quences sont donn�es aux transactions qui en ont besoin et ne sont pas bloqu�es jusqu'� la fin de la transaction. Ceci cr�e des trous dans le num�rotage pour les transactions annul�es.
Les OID sont la r�ponse de PostgreSQL aux identifiants de lignes uniques. Chaque ligne cr��e dans PostgreSQL obtient un OID unique. Tous les OID g�n�r�s pendant initdb sont inf�rieurs � 16384 (voir include/access/transam.h). Tous les OID cr��s par un utilisateur sont sup�rieurs ou �gaux � ceci. Par d�faut, tous ces OID sont uniques non seulement dans une table ou une base mais unique � l'int�rieur d'une installation PostgreSQL enti�re.
PostgreSQL utilise les OID dans ses tables syst�me interne pour lier les lignes entre tables. Ces OID peuvent �tre utilis�s pour identifier des lignes utilisateurs sp�cifiques et utilis�s dans des jointures. Il est recommand� que vous utilisiez le type de colonne OID pour stocker des valeurs OID. Vous pouvez cr�er un index sur le champ OID pour un acc�s plus rapide.
Les OID sont attribu�s pour toute ligne d'un endroit central qui est utilis� par toutes les bases de donn�es. Si vous voulez changer l'OID en quelque chose d'autre ou si vous voulez faire une copie de la table avec les OID originaux, il n'y a pas de raisons pour ne pas le faire :
CREATE TABLE nouvelle_table (macolonne int);
SELECT oid AS ancienne_oid, macolonne INTO table_temporaire FROM ancienne_table;
COPY table_temporaire FROM '/tmp/tablepg';
COPY nouvelle_table WITH OIDS FROM '/tmp/tablepg';
DROP TABLE table_temporaire;
Les OID sont stock�s en tant qu'entiers de quatre octets et d�borderont � quatre milliards. Personne n'a jamais rapport� un tel cas et nous avons pr�vu de retirer la limite avant que cela ne se produise.
Les TIDs sont utilis�s pour identifier des lignes physiques sp�cifiques avec des valeurs de bloc et d�calage. Les TID changent apr�s que les lignes aient �t� modifi�s ou recharg�s. Ils sont utilis�s par des entr�es d'index pour pointer vers des lignes physiques.
Une partie du code source et de l'ancienne documentation utilisent des termes dont l'usage est plus commun. Voici quelques exemples :
Une liste des termes g�n�raux pour le domaine des bases de donn�es est disponible sur : http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html
Vous manquez probablement de m�moire virtuelle sur votre syst�me ou votre noyau a une limite assez basse pour certaines ressources. Essayez ceci avant de lancer postmaster :
ulimit -d 262144
limit datasize 256m
Suivant votre shell, seul un d'eux pourrait r�ussir mais cela configurera
d'une fa�on plus importante la taille du segment de donn�es de votre
processus. Cette commande s'applique au processus actuel et � tous les
processus lanc� par celui-ci. Si vous avez des probl�mes avec le client
SQL parce que le processus serveur renvoie trop de donn�es,
essayez �a avant de lancer le client.
A partir de psql, tapez SELECT version();
Vous avez besoin de placer BEGIN WORK et COMMIT
autour de chaque utilisateur de gros objets, c'est-�-dire pour entourer
lo_open ... lo_close.
Actuellement, PostgreSQL force cette r�gle en fermant les gros objets lors de la transaction. Donc, le premier essai d'op�rations sur ces objets, fonctionnant habituellement (au moins la plupart du temps) aura un invalid large obj descriptor. Donc le code, auparavant fonctionnel (au moins la plupart du temps), g�n�rera maintenant un message d'erreur si vous n'utilisez pas de transaction.
Si vous utilisez une interface client interface comme
ODBC, vous aurez peut-�tre besoin de lancer
auto-commit off.
Utilisez CURRENT_TIMESTAMP:
CREATE TABLE test (x int, heuremodif timestamp DEFAULT CURRENT_TIMESTAMP );
IN sont-elles si lentes ?Dans les versions pr�c�dant la 7.4, les sous-requ�tes ont �t� jointes avec
des jointures externes en parcourant s�quentiellement le r�sultat de la
sous-requ�te pour chaque ligne de la requ�te externe. Si la sous-requ�te
renvoit quelques lignes et que la requ�te externe en renvoit plein,
IN sera plus rapide. Pour acc�l�rer les autres
requ�tes, remplacez IN avec EXISTS :
SELECT *
FROM table
WHERE colonne IN (SELECT souscolonne FROM soustable);
to:
SELECT *
FROM table
WHERE EXISTS (SELECT souscolonne FROM soustable WHERE souscolonne = colonne);
Pour que ceci soit rapide, souscolonne doit �tre une colonne
index�e.
A partir de la version 7.4, IN utilise actuellement les m�mes
techniques sophistiqu�es de jointures comme des requ�tes normales et est
pr�f�r� � l'utilisation de EXISTS.
PostgreSQL supporte les jointures externes en utilisant la syntaxe SQL standard. Voici deux exemples :
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
Ces requ�tes identiques joignent t1.col � t2.col et renvoient toute colonne non jointe de t1 (celles sans correspondance dans t2). Une jointure droite (RIGHT join) ajoutera les lignes non jointes de t2. Une jointure compl�te (FULL join) renverra les lignes correspondantes ainsi que les lignes non jointes de t1 et t2. Le mot cl� OUTER est optionnelle et assum� dans le cas de jointure LEFT, RIGHT et FULL. Les jointures ordinaires sont appel�es des jointures INNER.
Lors des pr�c�dentes versions, les jointures externes peuvent �tre
simul�es en utilisant UNION et NOT IN. Par
exemple, lors d'une jointure de tab1 et tab2, la requ�te
suivante r�alise une jointure externe, outer, des deux tables :
SELECT tab1.col1, tab2.col2
FROM tab1, tab2
WHERE tab1.col1 = tab2.col1
UNION ALL
SELECT tab1.col1, NULL
FROM tab1
WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
ORDER BY col1
Il n'existe pas de moyens de lancer des requ�tes sur une autre base que la courante. Comme PostgreSQL charge des catalogues syst�mes sp�cifiques � la base de donn�es, sa r�action aux requ�tes inter-base de donn�es est incertaine.
contrib/dblink permet les requ�tes entre bases de donn�es en utilisant des fonctions. Bien s�r un client peut r�aliser des connexions simultan�es � plusieurs bases de donn�es et joindre les r�sultats du c�t� client.
A partir de la 7.3, vous pouvez facilement renvoyer plusieurs lignes ou colonnes � partir d'une fonction, http://techdocs.postgresql.org/guides/SetReturningFunctions.
PL/PgSQL cache le contenu des fonctions et un effet de bord malheureux est que si une fonction PL/PgSQL acc�de � une table temporaire, que cette table est ensuite supprim�e et recr��e, et que la fonction est appel�e de nouveau, la fonction �chouera car le contenu de la fonction cach�e pointera toujours vers l'ancienne table temporaire. La solution revient � utiliser EXECUTE pour l'acc�s aux tables temporaires avec PL/PgSQL. Ceci obligera l'analyse de la requ�te � chaque fois.
Il peut y avoir plusieurs raisons. Essayez tout d'abord votre fonction utilisateur dans un programme de test.
Envoyez vos extensions � la liste de diffusion pgsql-hackers, elles atterriront �ventuellement dans le sous-r�pertoire contrib/.
Dans les versions de PostgreSQL � partir de 7.3, les fonctions qui renvoient une table sont totalement support�es en C, PL/PgSQL, et SQL. Voir le Guide du Programmeur pour plus d'information. Un exemple de fonction renvoyant une table d�finie en C se trouve � contrib/tablefunc.
Les Makefiles n'ont pas les d�pendances ad�quates pour les fichiers d'en-t�te. Il vous faut faire make clean puis un autre make. Si vous utilisez GCC, vous pouvez utiliser l'option --enable-depend de configure pour que le compilateur calcule les d�pendances automatiquement.