Index of /postgresql/FAQ/FAQ_french.html |
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-2007, 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.
HIVE: All information for read only. Please respect copyright! |
