Vous n'êtes pas identifié(e).
Créez une vue, implémentez une règle pour un INSERT massif et dans votre règles faites deux requêtes :
INSERT INTO ...
...
WHERE NOT EXISTS (...)
et
UPDATE ...
...
WHERE EXISTS (...)
Au niveau client, traitez tout comme une simple insertion.
A +
PostGreSQL ayant un opérateur LIKE conforme à la norme, il suffit d'utiliser le mot clef ESCAPE dans le LIKE pour ce faire, en évitant d'utiliser un caractères d'échappement qui à déjà une signification par ailleurs.
Exemple : LIKE '_%§_%_' ESCAPE '§'
Les, caractères rarements employés et disponible au clavier sont :
$ $ µ § } ] ^ ` [ {
A +
Bonjour,
viens de paraître, la 2e édition plus complète sur la modélisation des données via UML2, de Christian Soutou et Frederic Brouard (alias SQLpro sur DVP).
http://www.eyrolles.com/Informatique/Li … 2212134131
Ce n'est certes pas spécifique à PostGreSQL, mais c'est le point de départ de toute base de données relationnelle.
Chapitres abordés :
Le niveau conceptuel
Analyse des besoins
Les concepts majeurs
Les identifiants
...
Le niveau logique
Concepts du niveau logique
Du conceptuel au relationnel
Typez vos colonnes
...
Le niveau physique
Le langage SQL
Passage du logique au physique
Programmation des contraintes
...
Le niveau externe
Les vues relationnelles (SQL2)
Les vues matérialisées
Les vues objet (SQL3)
Les déclencheurs INSTEAD OF
Les outils du marché : de la théorie à la pratique
MagicDraw
MEGA
Modelio
...
A. Corrigés des exercices
B. Ressources
Vos commentaires sont les bienvennus.
A +
PostGreSQL est il un vrai SGBD Relationnel ? Au regard des règles de Codd et des réflexions de Chris Date, il semblerait que non.
Voici quelques éléments qui vous permettrons d’apprécier les limites de PostGreSQl et de trouver certains moyens de contournement.
Mais les choses s'améliorent !
A lire donc : [site]http://blog.developpez.com/sqlpro/p1091 … lationn-1/[/site]
Vos remarques sont les bienvennues.
Merci
Comme tous les SGBDR, PostGreSQL effectue des opérations d'écriture de fichier asynchrones entre data et transaction afin d'en optimiser l'écriture. La capture des IO d'une racine de stockage d'une base de données à des fins de reproduction vers un autre serveur ne peut en aucun cas garantir une bonne fin des opérations en cas de crash et vous pouvez vous retrouver in fine dans une situation ou la base est considérée comme corrompue par le serveur et donc définitivement inexploitable.
Même les outils professionnels et payant comme Double Take ne garantissent pas une telle reprise.
Voici ce que je dis dans le chapitre 11 "Administration" de mon ouvrage sur SQL à paraître dans 3 mois (4e edition) :
"
6.5 – Réplication des IO des fichiers des bases
Des solutions vendues dans le commerce permettent de répliquer les IO d’une base de données, voire de tout un serveur. C’est par exemple DoubleTake de Vision Solutions ou encore Left Hand de Hewlett-Packard. Le principe en est simple : chaque opération d’écriture sur un fichier, une arborescence, sur un disque ou même sur toute une baie est envoyée par réseau à un système homologue qui récrit les IO ainsi capturées.
Si l’offre est séduisante, elle n’est reste pas moins discutable :
• De par la nature des écritures dans les fichiers de données (pages, voir extensions), ce sont souvent des quantités importantes qui sont écrites, même si ce n’est que cycliquement (une seule donnée d’une seule ligne modifiée dans une table nécessite la récriture au minimum de la page complète) ;
• La vitesse d’écriture dans les journaux de transactions, même s’ils sont Write Ahead, peut conduire à des goulets d’étranglement sur une base de données fortement transactionnelle. Qu’en sera-t-il du réplica ?
• Comme nous l’avons déjà dit, le mode asynchrone des écritures entrecroisées entre données et transactions, propre aux SGBDR, peut conduire, en cas d’arrêt brutal, et avec un système supplémentaire lui-même asynchrone, à une situation irrécupérable de la base, malgré des fichiers intrinsèquement en bon état.
Il est en effet rarissime que ces mécanismes soient synchrones, sinon cela pénaliserait trop le système d’origine, tirant irrémédiablement les performances vers le bas.
Dès lors, aucune de ces solutions ne peut garantir une parfaite bonne fin en cas de crash !
"
Merci e na pas réproduire.
A +
...
Je suis d'accord avec flo pour dire que le problème principal est de repérer efficacement ce qui a bougé. Une fois ce souci résolu, qui est plutôt fonctionnel que technique, on peut chercher une solution pour la synchro des données.
Il suffit d'utiliser l'outil Oracle approprié qui est Change Data Capture : http://docs.oracle.com/cd/B13789_01/ser … 36/cdc.htm
A +
Cette requête n'est-elle pas suffisante :
CREATE TABLE T
(esp INT,
num INT,
periode INT
)
INSERT INTO T
VALUES
(1, 563, 1001),
(1, 2040, 1001),
(1, 12, 1001),
(1, 123, 1001),
(1, 987, 1001),
(1, 563, 1002),
(1, 569, 1002),
(1, 12, 1002),
(1, 13, 1002),
(1, 563, 1003),
(1, 569, 1003),
(1, 2040, 1003),
(1, 12, 1003),
(1, 123, 1003),
(1, 6, 1003);
SELECT T1.periode, T1.num
FROM T AS T1
INNER JOIN T AS T2
ON T1.periode = T2.periode -1
AND T1.num = T2.num???
A +
Fichier bien trouvé, mais vide. j'ai fait une recherche globale pour savoir s'il n'y en avait pas un autre... Peine perdu.
Après suppression c'est OK.
merci messieurs !
Bonjour.
La raison la plus probable est que vous avez lancé une très longue commande sql dans l'interface, et qu'à l'ouverture de la fenêtre pgAdmin charge cette requête en mémoire (une liste des x dernière requêtes est stockée) ce qui peut être long selon la taille de la requête que vous avez effectuée.
Si c'est effectivement le cas, vous devez modifier le fichier c:\utilisateurs\votre utilisateur\AppData\Roaming\postgresql\pgadmin_histoqueries.xml (qui risque alors de faire plusieurs dizaines ou centaines de Ko) et y supprimer la requête concernée, ou juste supprimer ce fichier devrait également fonctionner.
Normalement la désinstallation (avec suppression des bases) aurait du supprimer ce fichier ?
Je tente la chose;..
A +
Bonjour,
suite à un dysfonctionnement de PGAdminIII, j'ai désinstallé puis réinstallé PostGreSQL et PGAdmin III, mais le problème persiste :
Sous Windows 7 Intégrale
PostgreSQL 2.0 et 2.1
PGAdmin 1.14.1
Lors de l'appui sur l’icône "SQL" dans PGAdmin III ce dernier reste enfoncé éternellement et rien ne se produit. Un des processeurs est scotché au max avec l'exécution de PGadmin III.
La seule solution est de tuer la tâche PGAdmin III
Aucun autre symptôme... que les rapport de kill de la tâche :
Version=1
EventType=AppHangB1
EventTime=129734235314592169
ReportType=3
Consent=1
UploadTime=129734235382696065
ReportIdentifier=c0bbef3c-548c-11e1-8041-90004e9c85c6
IntegratorReportIdentifier=c0bbef3d-548c-11e1-8041-90004e9c85c6
WOW64=1
Response.type=4
Sig[0].Name=Nom de l’application
Sig[0].Value=pgadmin3.exe
Sig[1].Name=Version de l’application
Sig[1].Value=1.14.1.0
Sig[2].Name=Horodatage de l’application
Sig[2].Value=4ed8f008
Sig[3].Name=Signature de blocage
Sig[3].Value=fbc0
Sig[4].Name=Type de blocage
Sig[4].Value=0
DynamicSig[1].Name=Version du système
DynamicSig[1].Value=6.1.7601.2.1.0.256.1
DynamicSig[2].Name=Identificateur de paramètres régionaux
DynamicSig[2].Value=1036
DynamicSig[22].Name=Signature de blocage supplém. 1
DynamicSig[22].Value=fbc0c1f3b88b86a4d3cd1d251f4161c0
DynamicSig[23].Name=Signature de blocage supplém. 2
DynamicSig[23].Value=bd7a
DynamicSig[24].Name=Signature de blocage supplém. 3
DynamicSig[24].Value=bd7aae4c9072c1cea02b24081491cd9d
DynamicSig[25].Name=Signature de blocage supplém. 4
DynamicSig[25].Value=fbc0
DynamicSig[26].Name=Signature de blocage supplém. 5
DynamicSig[26].Value=fbc0c1f3b88b86a4d3cd1d251f4161c0
DynamicSig[27].Name=Signature de blocage supplém. 6
DynamicSig[27].Value=bd7a
DynamicSig[28].Name=Signature de blocage supplém. 7
DynamicSig[28].Value=bd7aae4c9072c1cea02b24081491cd9d
UI[3]=pgAdmin III - PostgreSQL Tools ne répond pas
UI[4]=Si vous fermez le programme, vous risquez de perdre des informations.
UI[5]=Fermer le programme
UI[6]=Fermer le programme
UI[7]=Fermer le programme
LoadedModule[0]=C:\Program Files (x86)\pgAdmin III\1.14\pgadmin3.exe
LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll
LoadedModule[2]=C:\Windows\syswow64\kernel32.dll
LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll
LoadedModule[4]=C:\Program Files (x86)\pgAdmin III\1.14\wxbase28u_vc_custom.dll
LoadedModule[5]=C:\Windows\syswow64\USER32.dll
LoadedModule[6]=C:\Windows\syswow64\GDI32.dll
LoadedModule[7]=C:\Windows\syswow64\LPK.dll
LoadedModule[8]=C:\Windows\syswow64\USP10.dll
LoadedModule[9]=C:\Windows\syswow64\msvcrt.dll
LoadedModule[10]=C:\Windows\syswow64\ADVAPI32.dll
LoadedModule[11]=C:\Windows\SysWOW64\sechost.dll
LoadedModule[12]=C:\Windows\syswow64\RPCRT4.dll
LoadedModule[13]=C:\Windows\syswow64\SspiCli.dll
LoadedModule[14]=C:\Windows\syswow64\CRYPTBASE.dll
LoadedModule[15]=C:\Windows\syswow64\SHELL32.dll
LoadedModule[16]=C:\Windows\syswow64\SHLWAPI.dll
LoadedModule[17]=C:\Windows\syswow64\ole32.dll
LoadedModule[18]=C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCP90.dll
LoadedModule[19]=C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
LoadedModule[20]=C:\Program Files (x86)\pgAdmin III\1.14\wxbase28u_xml_vc_custom.dll
LoadedModule[21]=C:\Program Files (x86)\pgAdmin III\1.14\wxbase28u_net_vc_custom.dll
LoadedModule[22]=C:\Windows\system32\WSOCK32.dll
LoadedModule[23]=C:\Windows\syswow64\WS2_32.dll
LoadedModule[24]=C:\Windows\syswow64\NSI.dll
LoadedModule[25]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_adv_vc_custom.dll
LoadedModule[26]=C:\Windows\system32\WINMM.dll
LoadedModule[27]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_core_vc_custom.dll
LoadedModule[28]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
LoadedModule[29]=C:\Windows\system32\WINSPOOL.DRV
LoadedModule[30]=C:\Windows\syswow64\COMDLG32.dll
LoadedModule[31]=C:\Windows\syswow64\OLEAUT32.dll
LoadedModule[32]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_html_vc_custom.dll
LoadedModule[33]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_aui_vc_custom.dll
LoadedModule[34]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_stc_vc_custom.dll
LoadedModule[35]=C:\Program Files (x86)\pgAdmin III\1.14\wxmsw28u_xrc_vc_custom.dll
LoadedModule[36]=C:\Program Files (x86)\pgAdmin III\1.14\LIBPQ.dll
LoadedModule[37]=C:\Program Files (x86)\pgAdmin III\1.14\SSLEAY32.dll
LoadedModule[38]=C:\Program Files (x86)\pgAdmin III\1.14\LIBEAY32.dll
LoadedModule[39]=C:\Program Files (x86)\pgAdmin III\1.14\libintl-8.dll
LoadedModule[40]=C:\Program Files (x86)\pgAdmin III\1.14\libiconv-2.dll
LoadedModule[41]=C:\Windows\system32\Secur32.dll
LoadedModule[42]=C:\Windows\syswow64\WLDAP32.dll
LoadedModule[43]=C:\Program Files (x86)\pgAdmin III\1.14\libxml2.dll
LoadedModule[44]=C:\Program Files (x86)\pgAdmin III\1.14\iconv.dll
LoadedModule[45]=C:\Program Files (x86)\pgAdmin III\1.14\zlib1.dll
LoadedModule[46]=C:\Program Files (x86)\pgAdmin III\1.14\libxslt.dll
LoadedModule[47]=C:\Windows\system32\IMM32.DLL
LoadedModule[48]=C:\Windows\syswow64\MSCTF.dll
LoadedModule[49]=C:\Windows\system32\uxtheme.dll
LoadedModule[50]=C:\ProgramData\Real\RealPlayer\BrowserRecordPlugin\Chrome\Hook\rpchrome14browserrecordhelper.dll
LoadedModule[51]=C:\Windows\system32\apphelp.dll
LoadedModule[52]=C:\Windows\system32\dwmapi.dll
LoadedModule[53]=C:\Program Files\WIDCOMM\Bluetooth Software\SysWOW64\BtMmHook.dll
LoadedModule[54]=C:\Windows\syswow64\PSAPI.DLL
LoadedModule[55]=C:\Windows\syswow64\CLBCatQ.DLL
LoadedModule[56]=C:\Windows\system32\CRYPTSP.dll
LoadedModule[57]=C:\Windows\system32\rsaenh.dll
LoadedModule[58]=C:\Windows\system32\RpcRtRemote.dll
LoadedModule[59]=C:\Windows\system32\NLAapi.dll
LoadedModule[60]=C:\Windows\system32\napinsp.dll
LoadedModule[61]=C:\Windows\system32\pnrpnsp.dll
LoadedModule[62]=C:\Windows\system32\wshbth.dll
LoadedModule[63]=C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL
LoadedModule[64]=C:\Windows\System32\mswsock.dll
LoadedModule[65]=C:\Windows\system32\DNSAPI.dll
LoadedModule[66]=C:\Windows\System32\winrnr.dll
LoadedModule[67]=C:\Windows\system32\msimg32.dll
LoadedModule[68]=C:\Windows\System32\wshtcpip.dll
LoadedModule[69]=C:\Windows\System32\wship6.dll
LoadedModule[70]=C:\Windows\system32\IPHLPAPI.DLL
LoadedModule[71]=C:\Windows\system32\WINNSI.DLL
LoadedModule[72]=C:\Windows\system32\rasadhlp.dll
LoadedModule[73]=C:\Windows\System32\fwpuclnt.dll
FriendlyEventName=A cessé de fonctionner et a été fermé
ConsentKey=AppHangXProcB1
AppName=pgAdmin III - PostgreSQL Tools
AppPath=C:\Program Files (x86)\pgAdmin III\1.14\pgadmin3.exe
ReportDescription=Un problème a provoqué l’arrêt de l’interaction de ce programme avec Windows.
Bref, je ne sais pas quoi faire...
D'avance merci !
A +
Vous êtes confronté à un problème que je dénonce au sujet de PostGreSQL et qui pose de nombreux problèmes pour des bases à forte volumétrie et pour des requêtes complexes : l'absence de "hint" ou tag de requête, permettant de contraindre l'optimiseur à adopter une technique particulière (par exemple pour une jointure ou pour lire un index).
La plupart des SGBDR implémente ce genre de choses mais les concepteurs actuels de PostGreSQL sont contre l'existence de telle choses, en avançant un argument pour le moins naïf qui se résume en gros à : "postGreSQL est doté d'un optimiseur parfait pourvu qu'on fasse attention aux statistiques"... Bizarrement, Entreprise DB propose un PostGreSQL amélioré supportant ce type de tag, mais c'est payant !!!
J'ai eu l'occasion de faire débat sur ce sujet et biien d'autres, pour montrer comment la migration de grosses bases vers PG pouvait s'avérer cauchemardesques...
A lire, donc, afin de vous faire une opinion
Migration Oracle PostGreSQL : Les 13 grandes lacunes qui peuvent s'avérer cauchemardesque !
Oracle, SQL Server, postGreSQL
Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les écueils
Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL
A +
Pour ce qui est des colonnes calculées, les solutions sont actuellement limitées sous PG : il n'existe ni colonne calculée persistantes (calcul stocké avec les données)
Un trigger permet de le faire très bien.
Pas tout à fait... une colonne calculée est généralement calculée par différence pour optimiser. Rien à voir avec un trigger qui est l'un des éléments les plus contre performant d'un SGBDR...
ni index sur expression calculé,
C'est un index sur une expression, ce qui existe dans PostgreSQL, l'URL que vous donnez en étant la preuve (http://www.postgresql.org/docs/9.1/stat … ional.html).
Non, c'est un index sur fonction... Ce n'est pas le même chose, car vous ne pouvez pas créer une colonne calculée (donc une expression de calcul) et l'indexer...
La différence, peut être subtile, vous aura sans doute échappée... Et là encore il y a une différence de coût, donc d'optimisation, importante...
ni de vues indexées
Inutile sur PostgreSQL tant que PostgreSQL ne gère pas les vues matérialisées.
Vue matérialisée et vues indexées sont la même chose. Oracle les appelle matérialisées et SQL Server vue indexées, mais c'est la même chose. Juste une différence de dénomination !
A +
Une relation c'est l'objet mathématique porteur de données à l'origine de l'algèbre relationnelle de Codd...
pourquoi le terme relation ? On a oublié que lorsqu’un journaliste fait un compte rendu d'un événement, il relate les faits, il fait une relation de l'événement. Ce de ce sens profond que le terme relationnel vient.
A la différence d'une table les relations ont les propriétés suivantes :
- Les attributs d'une relation doivent pouvoir stocker n'importe quelle type d'information atomique (numérique, littéraux, images, son, vidéo...)
- Tous les attributs d'une relation doivent être valués (pas de NULL)
- Toute relation doit avoir une clef (équivalent de la clef primaire d'une table).
Pour ce qui est des colonnes calculées, les solutions sont actuellement limitées sous PG : il n'existe ni colonne calculée persistantes (calcul stocké avec les données) ni index sur expression calculé, ni de vues indexées... contrairement à oracle ou SQL Server.
Seule solution, créer une fonction et implémenter un index sur fonction. À lire : [url= 11.7]http://www.postgresql.org/docs/9.1/static/indexes-expressional.html]"11.7. Indexes on Expressions"[url]A +
1: Pas vraiment. On peut utiliser une contrainte check appelant une fonction, mais ça n'est pas officiellement supporté dans PostgreSQL si je me souviens bien
Ou avez vous vu cela ?
Pour ma part cela est supporté depuis longtemps et fait plutôt partie des bonnes pratiques, car c'est bien plus perormant qu'un trigger.
Pour information l'article ou j'ai démontré cela : Contraintes CHECK sur tables externe avec PostGreSQL
A +
faites un héritage au niveau de votre modèle et depuis la table mère ayez deux tables filles avec "le nom commun du champ servant de Primary Key (taID) des 2 fichiers users, la suite de leur description est différente (ie [...01] <> [...02])." Puis vous n'aurez qu'a greffer votre FK sur la table mère.
Sur l'héritage de données en générale, lisez l'article que j'ai écrit à, ce sujet : http://sqlpro.developpez.com/cours/mode … /heritage/
A +
De toute façon et comme je l'ai indiqué dans cet article, le commit à deux phases ou Two Phase Comit (2PC) ne garantit pas l'acidité des transactions, contrairement à ce que je voit trop souvent écrit, y compris dans certains manuel de PG comme : http://wiki.postgresql.org/images/8/86/ … cation.pdf page 12...
A +
ha parfait, je n'avais pas encore vu cela... Dommage que vous n'en ayez pas trop parlé dans vos présentation de la version 9... Ou bien j'ai raté quelque chose...
A +
J'ai lu quelque part qu'il existait le SQL/PSM, je connais très peu d'information là-dessus, je sais juste que c'est un langage normalisé (en 2003, donc récent) et qu'il était équivalent au T-SQL / PL/SQL / PL/pgSQL.
Probablement dans mon livre sur SQL... SQL, collection Synthex - Pearson Education
Petite précision : SQL/PSM est l'ensemble de la norme SQL qui spécifie les "Persistent Stored Module" (ISO/IEC 9075-4 - Part 4 : Persistent Stored Modules (SQL/PSM)), c'est à dire tout ce qui est code persistant dans la base, autrement dit les procédures stockées, les fonctions utilisateurs (UDF) et les déclencheurs.
Autrement dit n'importe quel SGBDR qui fait des procédures stockées, peut se réclamer PSM... Sauf que la plupart des implémentations de PSM sont non standards et donc pas portable d'un SGBDR à l'autre. Le SGBDR le plus proche de la norme SQL étant, encore aujourd"hui IBM DB2 UDB.
Enfin, oui, hélas, il n'est pas possible de faire des batch avec PG comme on le fait avec SQL Server ou Oracle, et c'est dommage !
A +
[...]
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
[...]Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
Selon vous je ne devrais faire que des articles positif sur PostGreSQL et ne jamais parler de choses qui fasse... C'est amusant. Je ne sais pas pourquoi, mais cela me rappelle certains époque comme celle de l'URSS.
De plus et contrairement à ce que vous pensez j'agit dans les deux sens : critique + aide, mais il semble que vous ne lisiez que mes critiques..
Voici quelques un des articles "positifs" :
SQL et système d'information géographique (SIG)
Contraintes CHECK sur tables externe avec PostGreSQL
UDF POSTGRESQL : créer des fonctions PL/pgSQL avec de nombreux exemples - PARTIE 1 - fonctions scalaires
A +
Tout marche à peu près bien. Je n'ai pas constaté de bug notoire. C'est juste un message d'info. mais les "nouveautées" ne seront pas vues graphiquement...
A +
Ce devient n'importe quoi ...
je ne suis pas administrateur, mais je me demande ce que Mr SQLPro (?!) fait sur ce forum.
Je ne vois pas l’intérêt de venir ici pour dénigrer Postgresql et vendre sa soupe (articles, blog, livres, SQLServer, ...).
Ce forum a pour objectif d'aider les gens, pas de passer son temps à troller sur des moteurs de base de données qui ne nous intéressent pas !
Je ne vais pas lire votre article, car le sommaire sonne déjà comme un appel au troll et est déjà complètement faux.Y a t'il une option ignorer dans ce forum ?
C'est bien de critiquer sans avoir lu ! Cela montre le niveau des intégristes de PostGreSQL...
A +
Pour le point 6, la vue pg_stat_all_indexes sert à quoi ?
Mea culpa, j'ai rectifié le tir !
Merci
A +
Un seul exemple me suffira, puisqu'ensuite je suppose que vous viendrez jouer de mauvaise foi ou répondrez à coté :
Il n'est pas non plus possible de savoir comment sont utilisés les index de la base et donc de supprimer les index inutilisés. Par exemple SQL Server propose la vue sys.dm_db_index_usage_stats pour connaitre l'utilisation de tous les index du serveur.
Il existe la même chose sur postgres, par exemple la vue pg_stat_user_indexes.
Pour votre "culture personnelle" également : http://docs.postgresqlfr.org/9.0/monitoring-stats.html
Là j'avoue que je n'ai effectivement pas vu cela.
Ce qui est dommage c'est que dans ces vues il n'y a pas le nombre de mises à jour d'index que l'on obtient par approximation au niveau table (un index n'est pas forcément mis à jour lors d'un update), ce qui serait très pratique pour décider de retirer ou non l'index.
Malgré cela il n'existe rien pour savoir quels index sont à poser !
A +
SQLpro a écrit :Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.Au vu de vos articles, ce qu'il en ressort selon vous est qu'il ne faut jamais choisir postgresql, en donnant une argumentation plus que partiale. Si vous donniez toutes les informations et non celles qui vous arrangent, là effectivement cela enrichirait la discussion.
Ainsi, poster un article presque entièrement erroné, montrant votre méconnaissance de postgresql et un certain acharnement à le critiquer, sur un forum d'entraide pousse effectivement les gens à vous prendre pour "un affreux jojo anti Postgresql".
Montre moi les erreurs que j'ai commise. Donnez moi vos argument. Vos précédents arguments était faux. Montrez moi simplement un bout de code qui infirme ce que j'ai écrit... Ou bien des exemples concrets sur des sites crédibles...
Moi je m’intéresse aux faits. pas aux paroles partisanes.
SQLpro a écrit :Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
Je peux me tromper la dessus mais il me semble que c'est un choix des développeurs, motivés par le fait que :
1- Le SGBD est en grande majorité plus au courant que le développeur de la viabilité d'un plan d'exécution qu'un autre
2- Forcer l'utilisation d'un index peut se révéler quelques temps plus tard un mal plus qu'un bien selon l'évolution de la base, un index n'étant pas non plus une solution magique.
Pour un développeur lambda oui. Mais pour un DBA il en va tout autrement. Un bon DBA sait qu'aucun optimiseur au monde n'est parfait et qu'il faut de temps à autre intervenir sur un plan de requête. Il y a des dizaines d'ouvrages très sérieux sur ce sujet et des dizaines de milliers d'articles pour voir et comprendre pourquoi c'est utile.
Je vous en donne quelques références pour votre culture personnelle :
SQL Tuning
Principles of Database Query Processing for Advanced Applications
SQL Server Execution Plans
Cost-Based Oracle Fundamentals
Inside the SQL Server Query Optimizer
Au final, bien paramétrer sa base de donnée et s'assurer de bonnes statistiques n'a à ma connaissance jamais empêcher la résolution d'un problème de non utilisation d'un index sur postgresql.
Si j'ai même donné un exemple ou cela pourrait être utile dans mon article. Visiblement vous ne lisez toujours pas correctement.
Donc, rappel :
Les 13 grandes lacunes de PostGreSQL ou comment une migration Oracle PG peut s'avérer cauchemardesque !
Paragraphe 4 - Pas de tag (hint) pour forcer les plans de requête
Exemple avec la table T
Si cela ne vous convient toujours pas, libre à vous de proposer un patch proposant cette fonctionnalité, et ainsi enrichir le système, ou d'entamer des discussions avec les développeurs, chose beaucoup plus constructive.
Je ne suis pas développeur. C'est un autre métier que le mien. Je suis architecte de données et à ce titre je m'intéresse aux bases de données sous toutes les coutures, avant et après l'exploitation :
Modélisation, création, structuration, optimisation, tuning, administration, monitoring...
C'est un vrai métier, dont visiblement vous n'avez pas entendu parlé !
Pour votre culture personnelle : Wikipedia : Administrateur de bases de données
C'est même un métier très rémunérateur, puisque les salaires sont en général plus élevés que ceux des responsables systèmes...
A +
La philosophie du projet Postgres est assez claire en ce qui concerne la gestion de l'espace de stockage: vous devez superviser l'espace disque vous même. Et effectivement, cet espace de stockage ne se gère pas de la même façon qu'Oracle ou SQL Server. Je le vois comme une faiblesse et une force de Postgres: vous êtes plus limité mais le SGBD est bien moins complexe.
Donc à vous de mettre en œuvre une supervision pour que la saturation de l'espace disque n'arrive pas.
Je rejoints Frédéric sur l'absence de tablespace READ ONLY. J'aimerai bien que Postgres puisse disposer d'une telle fonctionnalité.Et concernant le dernier point, c'est encore la philosophie de Postgres qui entre en jeu. Les développeurs vous fournissent un noyau, le SGBD lui-même, et vous laisse la possibilité de l'enrichir à votre guise. Ainsi sont nés un certain nombre de projets annexes, et notamment Slony et Londiste qui répondent au besoin de réplication des données.
Cdt,
Thomas
Merci de vos commentaires.
Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.
Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
A +
