Le problème est que la compression systématique des LOBs avec TOAST joue en votre défaveur sur les données spatiales, car le contenu des données spatiale est assez aléatoire ce qui fait que le volume augmente légèrement au lieu de diminuer. Et il n'y a aucun moyen de désactiver TOAST, à moins de recoder le moteur PostgreSQL… (vous pouvez le faire!!!).
De plus PostgreSQL ne supporte pas la compression des données des tables et des index que l'on trouve dans d'autres SGBDR comme Microsoft SQL Server… ce qui permettrait de réduire considérablement le volume des autres données purement relationnelles.

Bref, PostgreSQL c'est double peine ! Compression obligatoire des LOBs, parfois inutile et contre-performantes pour certaines données, et impossibilité de compresser les autres données !

A +

Bonjour,

La CAF vient de migrer ses bases PostgreSQL sous Oracle en cloud, réduisant ainsi quelques 150 bases (et presque autant de serveur) à une seule base, de manière, notamment, à réduire ses coûts…

A +

De toutes façons, PostGreSQL est encore très loin des standards en matière de collation.  Voici une base créée avec la collation "French.France.1252" (qui est en fait un jeu de caractères et pas vraiment une collation). Démonstration :

CREATE TABLE T_MOT (MOT VARCHAR(32));

INSERT INTO T_MOT VALUES ('Retraite'), ('retraite'), ('retraité'), ('Retraité'), ('RETRAITÉ'), ('RETRAITE');

SELECT * FROM T_MOT ORDER BY MOT;

Résultat :

"retraite"
"Retraite"
"RETRAITE"
"retraité"
"Retraité"
"RETRAITÉ"

Or la règle en français est de placer les mots accentués avant les mots sans accents...

Le mot clef  COLLATE est très mal supporté et la documentation est plus que obscure... Impossible de savoir quelle combinaison de jeux de caractères / collation il faut pour pouvoir :
* faire indifféremment des recherches sensibles ou non à la casse (indépendamment des accents et autres caractères diacritiques)
* faire indifféremment des recherches sensibles ou non aux caractères diacritiques (indépendamment de la casse)

Un cas pertinent est de pouvoir trouver le mot "maïs" sans obtenir le mot "mais" quelque soit la casse.

INSERT INTO T_MOT VALUES ('maïs'), ('MAÏS'), ('Maïs'), ('Mais'), ('mais'), ('MAIS');  

SELECT * FROM T_MOT WHERE MOT = 'maïs';

Il reste la solution de faire un LOWER, mais cela ne devient plus "sargable" donc les performances sont en chute libre !

A +

Le problème vient du fait que vous faites du décisionnel sur un serveur de bases de données relationnel (ROLAP). Or dans ce cas, la plupart du temps, il faudra lire séquentiellement l'intégralité des lignes des tables en jeu. Il vous faut donc une RAM au moins équivalent à la plus grande table, voire à la base entière si jointure il y a...

Le mieux serait d'avoir un véritable moteur décisionnel, car ces derniers ne stockent pas les données de la même façon, afin d'accélérer les manipulations :
1) il y a compression des données (contrairement aux bases relationnelles ou cela couterait trop cher du fait des mises à jour incessantes)
2) le NULL n'est pas stocké (contrairement aux bases relationnel ou le changement d'état d'une donnée est courante, passant du NULL à une valeur)
3) certains agrégats sont pré-calculés afin de diminuer l'accès aux données (voir la règle 4 de Codd sur le décisionnel : "la rapidité d'extraction de l'information ne doit pas être dépendante du volume des données à traiter, mais du volume des données restituées")
4) certains SGBD Décisionnel font du cache de résultat en sus de la règle 3

Ces deux dernières règles n'ayant aucun intérêt dans un SGBD Relationnel, car l'état des informations changent tout le temps du fait des multiples transactions dans la journée, ce qui n'est pas le cas du décisionnel dans lequel on "statifie" les données.

Parmi les SGBD Décisionnel il y a :
* Terradata
* Oracle (BI Suite)
* SQL Server (SSAS/SSRS)

A +

Désolé de vous contredire, mais la plupart des SGBD Relationnels comme Oracle ou SQL Server proposent une méthode identique ou similaire pour ce faire. Oracle avec BFile et SQL Server avec FILESTREAM (depuis le version 2005, soit 10 ans)...

A +

Effectivement ce sont les "round trips" c'est à dire les aller et retour entre serveur et client, autrement dit les temps réseau, qui bouffent (à vue de nez) 99,9% de votre temps de traitement...

Ceci n'est pas nouveau et c'est généralement lié au style de développement. Plus vous mettrez de code ensembliste côté serveur SGBDR plus les performances seront importante...

À me lire : http://img1.lemondeinformatique.fr/fich … aisses.pdf

A +

Vous n'avez pas bien cherché : Une seule base de données ou plusieurs ?

De plus PostGreSQL n'est pas multibase dans le sens ou il n'est pas possible de faire des requêtes (SELECT, INSERT, UPDATE, DELETE) facilement entre différentes bases (il faut passer par des db_link) et encore moins des transactions entre différentes bases...

Enfin la catastrophe arrive si vous considérez le point de vue des sauvegardes/restauration. En effet rien ne permet der synchroniser la sauvegardes des différentes bases, ce qui fait qu'à la restauration vous pouvez avoir des factures sans client, des lignes de commande sans commande.....

A +

La notion de clef secondaire n'existe pas; On parle de :
clef primaire (NOT NULL et UNIQUE)
clef alternative ou subrogée (UNIQUE et NULLable)

A +

Le nombre de bug de SQL Server est bien moindre, tous moteurs confondus (SQL Server contient un ETL de nom SSIS, un moteur de stockage décisionnel en plus du relationnel, des outils de data mining et de formation de datamart SSAS, des outils de reporting SSRS et de très nombreux outils de maintenance, audit et admin......etc.) que ceux de PG... SQL Server compte à peu près 30 fois plus de code que PG, pour juste 20 fois moins de bug... Lisez les métriques du NIST par exemple sur les vulnérabilités... N'avez vous pas eu récemment une vulnérabilité importante sur PG récemment ? Depuis 2010, 26 vulnérabilités ont été recensées dans PG (http://www.postgresql.org/support/security/) contre 5 dans SQL Server (source NIST)... Comparez au volume de code, cela fait donc 150 fois plus de problème relativement dans PG que dans SQL Server... une toute petite paille !

A +

je tenais aussi à signaler que lorsque j'ai posté le bug dans la liste celui-ci n'a pas été publié... Peut être une modération à priori.. Ok, mais par exemple dans Microsoft Connect, il n'y a pas de modération (PostGreSQL aurait-il il des choses à cacher ???). Certes, il faut se faire reconnaître préalablement chhez MS, mais cela ne prends que quelques secondes...
Raisons pour laquelle j'ai ignoré la liste :
1) par le fait que le mail m'ait été adressé personnellement
2) parce que celui ci n'étais pas diffusé sur la liste au moment ou je suis aller y regardé.
3) mon client de messagerie, ne propose par par défaut l'option inclus donc le mail dans la liste de diffusion... (c'est d'ailleurs un outil Free : Mozilla !!!!! va falloir que je change pour OutLook...)

Ce midi, oui, et je fais le même constat que lui....
Comme je n'ais pas d'autres commentaires et que je gâche du temps à répondre à vos inepties...

je n'ai tout simplement pas eu le temps... Je ne consacre pas tout mon temps à PG... Je travaille aussi !

Quand à ma "non contribution" je considère qu'il s'agit de votre part d'une insukte. En effet une contribution pour éradiquer un bug qu'il ne vous plait pas de voir exposer est une insulte intellectuelles, à peu près équivalentes à celles des totalitarismes, qui ne supportent pas de voir exposer des défaillances dans leurs systèmes et préfèrent couper la tête à ceux qui les exposent !

MAIS C 'EST EXACTEMENT CE QUE J'AI FAIT !!!! J'AI ENVOYÉ LES DEUX À TOM LANE (ET MÊME 3 VERSION PAR SÉCURITÉ : TEXTE, XML et GRAPHIQUE !). DE PLUS JE VOUS L'AI DIT DANS MON PRÉCÉDENT POST MAIS VISIBLEMENT VOUS AVEZ UN PROBLÈME DE VUE !!!!

A +

Vos questions sont puériles, mais je vais vous répondre !

Ayant reçu un mail privé, j'ai répondu à ce mail. Est-ce mal ? Suis-je stupide ?

Je n'ais pas eu de réponse en retour de mon mail envoyé en privé !

N'ayant pas eu son retour je ne voit pas quelle réponse à apporter à aucune question en retour...

Et vous, avec ce post, pensez-vous réellement constructifs ? Moi je pense que vous maîtrisez l'art d'enculer les mouches...
D'autre part, il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server....
je suis revenu à 21h chez moi et j'avoue que je n'avais plus le temps de me consacrer àn PG...
Peut être êtes vous un fonctionnaire effectuant 32 h par semaine avec 8 semaines de congés payé.. pas moi, j'ai une boite à faire fonctionner et des cours à donner à des ingénieurs...

Vous simplifiez de manière parfaitement stupide l'envoi que j'ai fait; J'espère que c'est par ignorance... Car si c'était pas volonté, cela prouverait votre niveau de mauvaise foi...
Donc pour faire simple :
les plans de requête détaillés sont fournit par SQL Server sous forme XML dont voici un exemple :

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.1" Build="10.50.4000.0" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1" StatementEstRows="4" StatementId="1" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" StatementSubTreeCost="0.0133358" StatementText="SELECT *&#xD;&#xA;FROM   T_CLIENT_CLI AS C&#xD;&#xA;       FULL OUTER JOIN T_PROSPECT_PSP AS P&#xD;&#xA;            ON C.CLI_SIREN = P.PSP_SIREN&#xD;&#xA;            OR C.CLI_ENSEIGNE = P.PSP_ENSEIGNE" StatementType="SELECT" QueryHash="0x9365EE9F42E3675B" QueryPlanHash="0xBC472FE59224297A">
          <StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
          <QueryPlan CachedPlanSize="24" CompileTime="5" CompileCPU="5" CompileMemory="280">
            <RelOp AvgRowSize="57" EstimateCPU="0.00581814" EstimateIO="0.000939" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Full Outer Join" NodeId="0" Parallel="false" PhysicalOp="Merge Join" EstimatedTotalSubtreeCost="0.0133358">
              <OutputList>
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
              </OutputList>
              <Merge ManyToMany="true">
                <InnerSideJoinColumns />
                <OuterSideJoinColumns />
                <Residual>
                  <ScalarOperator ScalarString="[tempdb].[dbo].[T_CLIENT_CLI].[CLI_SIREN] as [C].[CLI_SIREN]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_SIREN] as [P].[PSP_SIREN] OR [tempdb].[dbo].[T_CLIENT_CLI].[CLI_ENSEIGNE] as [C].[CLI_ENSEIGNE]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_ENSEIGNE] as [P].[PSP_ENSEIGNE]">
                    <Logical Operation="OR">
                      <ScalarOperator>
                        <Compare CompareOp="EQ">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                            </Identifier>
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Compare CompareOp="EQ">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                            </Identifier>
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                    </Logical>
                  </ScalarOperator>
                </Residual>
                <RelOp AvgRowSize="33" EstimateCPU="0.0001603" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="3" LogicalOp="Clustered Index Scan" NodeId="1" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032853" TableCardinality="3">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                  </OutputList>
                  <IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
                    <DefinedValues>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                      </DefinedValue>
                    </DefinedValues>
                    <Object Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Index="[PK__T_CLIENT__D0BA12001DE57479]" Alias="[C]" IndexKind="Clustered" />
                  </IndexScan>
                </RelOp>
                <RelOp AvgRowSize="33" EstimateCPU="0.0001614" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Clustered Index Scan" NodeId="2" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032864" TableCardinality="4">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                  </OutputList>
                  <IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
                    <DefinedValues>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                      </DefinedValue>
                    </DefinedValues>
                    <Object Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Index="[PK__T_PROSPE__3FA9CAA424927208]" Alias="[P]" IndexKind="Clustered" />
                  </IndexScan>
                </RelOp>
              </Merge>
            </RelOp>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>

Trouvez vous cela plus facile que la représentation graphique ?

Bien entendu, c'est ce XML qui est interprété graphiquement. mais n'étant pas sur que Tom lane dispose de l'outil de lecture des plans, j'ai envoyé les deux par sécurité...
Ais-je bien fait ou suis-je à vos yeux un crétin ?

Effectivement, vous en avez tellement !!!

Mais ce qui est pire dans votre comportement, c'est que vous ne me donnez pas du tout envie de continuer à traiter ce sujet et donc votre mail aura l'effet inverse de celui escompté : j'abandonne la partie ! Ayant dû consacré 1h pour répondre à vos attaques infantiles, c'est 1h de perdu pour répondre à Tom lane...

A +

Oui, enfin, ça me fait penser aux temps anciens ou MS traitait ses bugs de "fonctionnalité particulière..."

Appelons un chat un chat. C'est un bug lié à une limitation du moteur SQL.

Je poste dans la bug liste en testant sur la dernière version 9.3.4.

A +