Les contraintes sur les colonnes ne sont par supportées dans PostgreSQL. En conséquence, le systèmes ne vérifie pas l'existence de doublons.
Sous 6.0, créez un index unique sur la colonne. Les tentatives de créer des doubles dans cette colonne donneront une erreur.
Les sous-requêtes imbriquées ne sont pas encore implantées, mais elles peuvent être simulées en utilisant des fonctions sql.
PostgreSQL 6.0 supporte les index "unique".
Actuellement, le système de règle dans PostgreSQL est pour la plupart non fonctionnel. Il fonctionne suffisamment pour supporter le mécanismes de vue, mais c'est tout. Vous utilisez les règles PostgreSQL à vos risques et périls.
Le système de gestion des grands objets est également non fonctionnel dans PostgreSQL. Il fonctionne juste assez pour stocker de grandes paquets de données et de les relire, mais l'implémentation souffre de quelques problèmes sous-jacents. Vous utilisez les grands objets PostgreSQL à vos risques et périls.
Non. Non. Non. Au moins, pas dans la distribution officielle. Quelques utilisateurs ont indiqué quelques succès dans l'utilisation de 'pgbrowse' et de 'onyx' comme frontaux à PostgreSQL. Plusieurs contributeurs travaillent sur des outils frontaux basés sur Tk. Posez la question dans la liste de diffusion.
PostgreSQL supporte une bibliothèque d'interfaçage que l'on peut appeler à partir de C nommée libpq de même qu'une bibliothèque d'interfaçage basée sur Tcl appelée libtcl.
D'autres ont contribué à une interface perl et à une passerelle WWW à PostgreSQL. Consulter la page d'accueil PostgreSQL pour plus de détails.
Utilisez une authentification basée sur l'hôte en modifiant le fichier $ PGDATA/pg_hba en conséquence.
Actuellement, il n'y a pas d'interface aisée pour mettre en place des groupes d'utilisateurs. Vous devez explicitement insérer/mettre à jour la table pg_group . Par exemple :
jolly=> insert into pg_group (groname, grosysid, grolist)
jolly=> values ('posthackers', '1234', '5443, 8261');
INSERT 548224
jolly=> grant insert on foo to group posthackers;
CHANGE
jolly=>
Les champs dans le fichier pg_group sont :
* groname: le nom de groupe. C'est un char16 et il doit être purement alphanumérique. Ne pas inclure de soulignés ou d'autres ponctuations. * grosysid: l'identificateur de groupe. C'est un int4. Il doit être unique pour chaque groupe. * grolist: la liste des identificateurs de pg_user qui appartiennent au groupe.
C'est un int4[].
Les curseurs normaux retournent les données en format ASCII. Puisque les données sont stockées d'origine en format binaire, le système doit effectuer une conversion pour produire le format ASCII. De plus, les formats ASCII sont souvent plus grands en taille que le format binaire. Une fois que les attributs sont retournés en ASCII, souvent l'application cliente doit alors les convertir en format binaire pour les manipuler.
Les curseurs binaires vous renvoient les données dans le format binaire, natif, de représentation. Donc, les curseurs binaires ont tendance à être plus rapides puisqu'il y a moins de temps de traitement dû à la conversion.
Toutefois, l'ASCII est neutre en ce qui concerne l'architecture alors que la représentation binaire peut différer entre différentes architectures de machines. Donc, si votre machine cliente utilise une représentation des données différente de votre machine serveur, recevoir les attributs en format binaire ne correspond certainement pas à ce que vous désirez. Donc, si votre objectif principal des d'afficher les données en ASCII, alors les recevoir en ASCII vous évitera quelques efforts côté client.
SQL spécifie les opérateurs d'inégalité < > , et c'est ce que nous avons définit comme types internes.
En 6.0, != est équivalent à < > .
Un index R-tree est utilisé pour indexer les données spatiales. Un index obtenu par hachage ne peut effectuer de recherches dans une gamme de données. Un index B-tree peut seulement effectuer des recherches dans une gamme de données sur une dimension. Les index R-tree permettent de traiter des données multidimensionnelles. Par exemple, si un index R-tree peut être construit sur un attribut de type 'point' le système peut répondre plus efficacement à des requêtes telles que sélectionner tous les points à l'intérieur d'un rectangle.
Le papier de référence qui décrit la conception originale du R-Tree est :
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." (R-Trees: une Structure d'Index Dynamique pour les Recherches Spatiales) Proc 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" (Lectures sur les Systèmes de Gestion de Base de Données)
Les Tuples sont limités à 8K octets. En tenant compte des attributs du système et autre surcharge, on devrait rester bien à l'écart des 8,000 octets pour être tranquille. Pour utiliser des attributs supérieurs à 8K, essayez d'utiliser l'interface pour les grands objets.
Les Tuples ne doivent pas franchir la frontière des 8k donc un tuple de 5k nécessitera un espace de stockage de 8k.
PostgreSQL ne maintient pas automatiquement de statistiques. On doit réaliser un appel à une "réorganisation" explicite pour mettre les statistiques à jour. Après que les statistiques aient été mises à jour, l'optimiseur fera un meilleur usage des index. Notez que l'optimiseur des limité et n'utilise pas les index dans certaines circonstances (telles que les dans les clauses OR).
Si le système ne voit toujours pas l'index, c'est probablement parce que vous avez créé un index sur un champ de type *_ops incorrect. Par exemple, vous avez créé un champ CHAR(4), mais vous avez spécifié un index de type_class char_ops.
Consultez la page du manuel sur create_index pour avoir des informations sur les types de classes disponibles. Il doit correspondre au type de champ.
Postgres ne prévient pas l'utilisateur quand un index incorrect est créé.
Les index ne sont pas utilisés dans les opérations ORDER BY.
Il y a deux pilotes ODBC disponibles, PostODBC et OpenLink ODBC.
Pour tous ceux qui sont intéressés par PostODBC, il y a maintenant deux listes de diffusion consacrées aux discussions sur PostODBC. Ce sont :
* [email protected] * [email protected]
ces listes sont des listes de diffusion ordinaires gérées par majordomo. Vous pouvez vous inscrire en envoyant un courrier électronique à :
OpenLink ODBC est actuellement en version bêta sous Linux. Vous pouvez le rapatrier de http://www.openlinksw.com/postgres.html Il fonctionne avec notre logiciel client ODBC standard vous aurez donc Postgres ODBC disponible sur toutes les plates formes clients que nous supportons (Win, Mac, Unix, VMS).
Nous vendrons probablement ce produit aux gens qui ont besoin d'un support de qualité commerciale, mais une version libre sera toujours disponible. Adressez vos questions à [email protected] .
Les R-Trees intégrés peuvent traiter les polygones et les boîtes. En théorie, les R-trees peuvent être étendus pour prendre en charge un plus grand nombre de dimensions. En pratique, l'extension des R-trees demande un peu de travail et n'avons actuellement aucun document sur la manière de le faire.
PostgreSQL supporte une syntaxe de type SQL LIKE de meme qu'un systeme de recherche
d'expressions regulieres plus general avec l'operateur ~. L'operateur !~ est
l'operateur de negation de recherche d'expressions regulieres. ~* et !~* sont les
operateurs d'expression regulieres indifferents aux majuscules et aux minuscules.
Vous ne devriez pas créer d'utilisateurs de base de données avec l'identificateur d'utilisateur 0(root). Ils seront incapables d'accéder à la base de données. C'est une mesure de précaution à cause de la possibilité pour chaque utilisateur de lier dynamiquement des modules objets au moteur de base de données.
Si le serveur se crash pendant une commande de réorganisation, il y a des chances pour qu'il laisse un fichier de verrouillage en suspend quelque part. Une tentative de relancer la commande de réorganisation résultera dans le
WARN:can't create lock file -- another vacuum cleaner running?
Si vous êtes sûr qu'il n'y a pas de réorganisation en cours, vous pouvez supprimer le fichier appelé "pg_vlock" dans le répertoire de votre base de données (qui est $ PGDATA/base/< dbName >)
Type Nom Interne Notes
--------------------------------------------------
CHAR char 1 caractere
CHAR2 char2 2 caracteres
CHAR4 char4 4 caracteres optimise pour une longueur fixe
CHAR8 char8 8 caracteres
CHAR16 char16 16 caracteres
CHAR(#) bpchar complete par des blancs jusqu'a la longueur fixe specifiee
VARCHAR(#) varchar la taille specifie la longueur maximum, pas de remplissage
TEXT text longueur limitee seulement par la longueur maximum du tuple
BYTEA bytea tableau d'octets de longueur variable
Rappelez vous, il vous faut utiliser le nom interne lorsque vous creez des index
sur ces champs ou quand vous effectuez d'autres operations internes.
Les quatre derniers types ci-dessus sont des types "varlena" (i.e. les quatre
premiers octets donnent la longueur, suivie par les donnees). CHAR(#) et VARCHAR(#)
allouent le nombre maximum d'octets quelle que soient les donnees stockees dans le
champ.
TEXT et BYTEA sont les seuls types caracteres qui ont une longueur variable sur le
disque.
PostgreSQL possède deux mots-clés intrinsèques, "isnull" et "notnull" (notez qu'il n'y a pas d'espaces). La Version 1.05 et suivante ainsi que la 6.* comprennent IS NULL et IS NOT NULL.
Insérez le mot 'EXPLAIN' au début de la requête, par exemple :
EXPLAIN SELECT * FROM table1 WHERE age = 23;
Postgres ne permet pas à l'utilisateur de spécifier une colonne utilisateur comme ayant le type SERIAL. A la place, vous pouvez utiliser le champ oid de chaque ligne comme valeur unique. Cependant, si vous avez besoin de vider et de recharger la base de données, vous serez obligés d'utiliser pgdump de postgres version 1.07 ou ultérieur ou 6.* avec l'option -o'ou COPY avec l'option WITH OIDS pour conserver les oids.
Une autre manière valide de le faire est de créer une fonction :
create table my_oids (f1 int4);
insert into my_oids values (1);
create function new_oid () returns int4 as 'update my_oids set f1 = f1 + 1; select f1 from my_oids; ' language 'sql';
puis:
create table my_stuff (my_key int4, value text);
insert into my_stuff values (new_oid(), 'hello');
Cependant, il faut garder à l'esprit qu'il y a compétition ici où un serveur peut effectuer une mise à jour, puis un autre serveur effectuer une mise à jour et que les deux sélectionnent le même nouvel identificateur. Cette instruction doit être effectuée dans le cadre d'une transaction.
Les Séquences sont implantées dans la version 6.1
Dans la version 6.0, vous ne pouvez pas directement créer un index multicolonnes en utilisant l'instruction "create index". Il vous faut définir une fonction qui agit sur les colonnes multiples, puis, utiliser "create index" avec cette fonction.
En 6.1, cette fonctionnalité est disponible.
Ce sont les fichiers temporaires "temp_ files" créés par l'exécuteur de requête. Par exemple, si un tri doit être effectué pour réaliser une instruction ORDER BY, quelques fichiers temporaires sont crées en résultat du tri.
Si vous n'avez pas de transactions ou de tri en cours à cet instant, vous pouvez supprimer ces fichiers temporaires "temp_ files" sans risques.
Si vous exécuter une réorganisation avec une version pre-6.0, les lignes non utilisées seront marquées pour être réutilisées, mais les blocs du fichier ne seront pas libérés.
En 6.0, une réorganisation réduit la taille des tables correctement.
La configuration par défaut permet uniquement de se connecter à partir de l'hôte tcp/ip localhost (machine locale). Vous devez ajouter une entrée pour un hôte supplémentaire dans le fichier pgsql/data/pg_hba.
Vous avez probablement utilisé :
create index idx1 on person using btree (name);
Les index PostgreSQL sont extensibles, et par conséquent en pre-6.0, vous devez spécifier un type de classe (class_type) quand vous créez un index. Lisez la page de manuel de create index (nommée create_index).
Avec la version 6.0, si vous ne spécifiez pas de type de classe (class_type), il prend par défaut le type correspondant à la première colonne.
Vous avez probablement définit un type de classe *_ops type incorrect pour le champ que vous voulez indexer.
Exécutez le fichier pgsql/src/tutorial/syscat.source. Il donne l'illustration de beaucoup de 'sélections' ('select's) à faire pour obtenir des informations sur les tables du système de gestion de base de données.
Vous avez compilé postgres avec flex version 2.5.3. Il y a un bogue dans cette version de flex. Utilisez la version 2.5.2 ou 2.5.4 de flex à la place. Il y a un fichier doc/README.flex qui doit faire un colmatage correct du code source flex 2.5.3.
Ce problème peut avoir son origine dans le noyau qui n'est pas configuré pour supporter les sémaphores.
Pour une intégration au web, PHP/FI est une excellente interface. L'URL pour cela est http://www.vex.net/php/
PHP est très bien pour des choses simples, mais pour si c'est plus compliqué, certains utilisent encore l'interface perl et CGI.pm.
Un exemple d'utilisation de WWW avec C pour dialoguer avec Postgres peut être essayé, il est à:
* http://www.postgreSQL.org/~mlc
Une passerelle WWW basée sur WDB utilisant perl peut être téléchargée de :
* http://www.eol.ists.ca/~dunlop/wdb -p95
PostgreSQL traite les modifications de données de manière différente de la plupart des systèmes de gestion de bases de données. Quand une ligne est modifiée dans une table, la ligne originale est marquée avec un horodatage du moment où cette modification est intervenue, et une nouvelle ligne est créée avec les données actuelles. Par défaut, seulement les données actuelles sont utilisées dans une table. Si vous spécifiez une donnée date/heure à la suite du nom de la table dans une clause FROM, vous pouvez avoir accès aux données qui étaient "actuelles" à ce moment là, i.e.
SELECT *
FROM employees
affiche les lignes d'employés dans la ligne au moment spécifié. Vous pouvez
spécifier des intervalles tels que
L'insertion (INSERT) de lignes reçoit également un horodatage, donc, les lignes qui n'étaient pas dans la table à l'instant désiré ne seront pas affichées.
La réorganisation supprime les lignes qui ne sont plus "actuelles" (courantes). La fonctionnalité "time-warp" est utilisée par le moteur du SGBD pour l'annulation des modifications et pour la restauration après un plantage. Les dates/heures d'expiration peut être fixés avec la commande purge.
En 6.0, après le nettoyage d'une table, la date de création d'une ligne peut être incorrecte, causant l'échec d'un parcours de la base de données basé sur les dates (time-travel).
Cette fonctionnalité de "time-travel" a été supprimé dans la version 7.0.
On peut faire deux choses. Vous pouvez utilisez l'option "Openlink" pour désactiver fsync() en lançant le postmaster avec l'option '-o -F'. Ceci évitera que des fsync() mettent à jour les données sur disque après chaque transaction.
Vous pouvez également utiliser l'option -B du postmaster pour accroître le nombre de mémoires tampon partagées que doivent se partager les différents processus en tâche de fond. Si vous donnez une valeur trop élevée à ce paramètre, le processus ne sera pas lancé ou se plantera de manière inattendue. Chaque tampon fait 8K et leur nombre est de 64 par défaut.
PostgreSQL dispose de plusieurs fonctions qui donnent des informations sur son état qui peuvent être utiles pour des besoins de débogage.
Tout d'abord, en compilant avec DEBUG définit, de nombreux assert()'s permettent de suivre l'avancement du processus de fond de plan et arrêtent le programme quand quelque chose d'inattendu se produit.
A la fois le postmaster et postgres ont plusieurs options de débogage. Premièrement, à chaque fois que lancez le postmaster, assurez-vous de rediriger la sortie standard et les messages d'erreurs vers un fichier d'enregistrement, comme :
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
Ceci créera un fichier server.log en tête de l'arborescence du répertoire de PostgreSQL. Ce fichier peut contenir des informations utiles concernant les problèmes et les erreurs rencontrés par le serveur. Postmaster possède une option -d qui permet d'obtenir des informations plus détaillées. L'option -d peut prendre une valeur de 1 à 3 qui spécifie le niveau de débogage. On obtient un fichier de débogage bavard qui peut être formaté en utilisant le programme 'indent'. (Il vous faudra peut être supprimer les lignes '====' dans les versions 1.*.) Faites attention au fait qu'un niveau de débogage supérieur à un entraîne la génération de fichiers d'enregistrement volumineux dans les versions 1.*.
Vous pouvez , en réalité, faire tourner le processus de fond de plan postgres à partir de la ligne de commande, et taper vos instructions SQL directement. Ceci n'est recommandé que SEULEMENT dans des situations de débogage. Notez qu'un caractère saut de ligne termine la requête, pas un point-virgule. Si vous avez compilé en utilisant les symboles de débogage, vous pouvez peut-être utiliser un débogueur pour voir ce qui se passe. Le processus de fond de plan n'ayant pas été lancé par le postmaster, il ne tourne pas dans un environnement identique et les problèmes d'interaction processus de fond de plan/verrouillage peuvent ne pas être reproduits. Quelques systèmes d'exploitation peuvent se connecter à un processus de fond de plan directement pour diagnostiquer les problèmes.
Le programme postgres possède les options a -s, -A, -t qui peuvent être très utiles pour la mise au point et pour la mesure de performances.
La commande EXPLAIN (Voir dans cette FAQ) permet de voir comment PostgreSQL interprète votre requête.
Les Oid sont la réponse de Postgres à des identificateurs de ligne uniques ou à des colonnes sérielles. Chaque ligne qui est créée dans Postgres reçoit un oid unique. Tous les oids générés par initdb sont inférieurs à 16384 (voir backend/access/transam.h). Tous les oids post-initdb (créés par un utilisateur) sont égaux ou supérieurs à cette valeur. Tous ces oids sont uniques, non pas seulement dans une table, ou une base de données, mais uniques à l'intérieur de l'installation postgres toute entière.
Postgres utilise les oids dans ses tables système internes pour relier les lignes de tables séparées. Ces oids peuvent être utilisés pour identifier des lignes spécifiques à un utilisateur et dans les jointures. On recommande l'utilisation de colonnes de type oid pour stocker des valeurs d'oids. Consulter les pages de manuel sql(l) pour voir les autres colonnes internes.
Les tids sont utilisés pour identifier des lignes physiques spécifiques contenant des valeurs de bloc ou de décalage. Les tids changent après une modification ou un rechargement des lignes. Ils sont utilisés par des enregistrements d'index pour pointer sur des lignes physiques. On ne peut pas y accéder par sql.
Des parties du code source et d'anciennes documentations utilisent des termes qui sont d'un usage plus commun. En voici quelques uns :
* row, record, tuple ligne, enregistrement, tuple * attribute, field, column attribut, champ, colonne * table, class table, classe * retrieve, select retrouver, sélectionner * replace, update remplacer, mettre à jour * append, insert ajouter, insérer * oid, serial value oid, valeur sérielle * portal, cursor portail, curseur * range variable, table name, table alias variable indiquant une étendue, nom de la table, alias de la table
Merci de me faire savoir si vous pensez à d'autres.
Le module GEQO dans PostgreSQL est sensé résoudre le problème d'optimisation de requête sur la jointure de plusieurs tables au moyen d'un Algorithme Génétique (GA). Il permet le traitement de grandes jointures par l'intermédiaire d'une recherche non--exhaustive.
Pour de plus amples informations voir README.GEQO [email protected] .
Il y avait un bogue dans 6.0 qui causait ce problème sous Solaris avec l'optimisation -O2. Passez à la version 6.1.
Editez include/storage/sinvaladt.h, et changez la valeur de MaxBackendId. Dans le futur, nous avons prévu de rendre ce paramètre configurable.
---------------------------------------------------------------------------
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre