Vous n'êtes pas identifié(e).
J'ai écrit un article sur ce sujet. Vous y trouverez les requêtes nécessaires pour ce faire : Où et comment sont stockées mes données avec PostGreSQL ?
A +
Par exemple une version corrective de PG pourrait mettre un fichier portant le même nom qu'un fichier d'une de vos table, ce qui écraserait ce fichier et ferait perdre des information de votre base en sus de la rendre incohérente !
A +
Ce que vous voulez, je présume, c'est savoir si vos deux requêtes donnent des résultats identiques ?
Si tel est le cas, la vérification se fait à l'aide de la formule algébrique suivante :
A - B U B - A = Ø
Soit en SQL la requête suivante :
WITH
T0 AS (requête SELECT 1),
T1 AS (requête SELECT 2)
SELECT * FROM T0
EXCEPT
SELECT * FROM T1
UNION ALL
SELECT * FROM T1
EXCEPT
SELECT * FROM T0A +
Poste en CDI chez le client final, basé sur Paris (9eme), rémunération: 50 / 60 KE.
Ca n'est pas énorme comme salaire...
Si je compare à mon activé au sein de ma boite, mon CA étant de plus de 150 000 € et avec 20% de frais, je touche plus de 80 K€ par an avec la possibilité de choisir mes clients et partir à la pêche quand je veut...
Donc à 25 % de moins, sauf l'avantage des 35 heures (rare dans cette activité) je voit pas l'intérêt !!!
A +
Cette requête :
UPDATE ONLY sas.I$AB01IN_ptg_pers
SET IND_UPDATE = 'N'
FROM geo.ptg_pers AS T
WHERE sas.I$AB01IN_ptg_pers.id = T.id
and ( (sas.I$AB01IN_ptg_pers.id_type_trt_ptg = T.id_type_trt_ptg)
or (sas.I$AB01IN_ptg_pers.id_type_trt_ptg IS NULL
and T.id_type_trt_ptg IS NULL));
Fait un OR dans la clause WHERE ce qui n'est pas seargable et oblige à lire toutes les données des tables et les remonte donc dans une table temporaire parce que sion en mémoire ce serait l'exlosion combinatoire.
Essayez de procéder en deux temps :
UPDATE ONLY sas.I$AB01IN_ptg_pers
SET IND_UPDATE = 'N'
FROM geo.ptg_pers AS T
WHERE sas.I$AB01IN_ptg_pers.id = T.id
and sas.I$AB01IN_ptg_pers.id_type_trt_ptg = T.id_type_trt_ptg;
UPDATE ONLY sas.I$AB01IN_ptg_pers
SET IND_UPDATE = 'N'
FROM geo.ptg_pers AS T
WHERE sas.I$AB01IN_ptg_pers.id = T.id
and sas.I$AB01IN_ptg_pers.id_type_trt_ptg IS NULL and T.id_type_trt_ptg IS NULL;A =
La grosse différence c'est que PostGreXC vient juste de passer de la bêta à la prod, alors que la réplication de fusion de MS pour SQL Server est implémentée depuis la version 7 soit en 1999... Bref, 14 ans de services sans problème ! Par exemple fnac.com.
Bref pour des base pêchues ou critiques, je ne mettrais pas ma main au feu postGressien dans l'immédiat !
A +
A ce jour, seul MS SQL Server et Oracle offrent des réplications intégrales de bases de données en config maître/maître à peu près satisfaisante. Oracle avec RAC, SQL Server avec la réplication de fusion qui permet d'ailleurs de ne pas tout répliquer : on peut sélectionner les tables à répliquer bidirectionnellement et même mettre des filtres sur les lignes des tables (clause WHERE), voir répliquer l'exécution de procédures stockées (moins couteux qu'un flux croisé de données).
Bref, si pour vous il est impératif d'avoir ce genre de fonctionnalité, changez pour Oracle ou MS SQL Server !!!
A +
Les vues matérialisées arrivent dans la version 9.3, mais elle ne sont pas synchrone ce qui revient donc au même que la requête de base dans ce cas précis. De plus elles posent un verrou exclusif sur l'intégralité de la table si j'ai bien compris.... Bref, pas génial ! En pour les rendre synchrone (eager... donc pas tout à fait synchrone, mais "au plus tôt") PG nous dit qu'il faut faire des triggers !!! On tourne en rond....
A +
Au passage ma chère Flo, dans les listes d'items, l'usage veut que l'on termine chaque item par un point virgule et le dernier par un point...
Donc :
1. faire des phrases (avec la ponctuation appropriée) --> point virgule manquant !
2. se relire afin de vérifier que les phrases en question sont compréhensibles (simplifier éventuellement), --> pas virgule... mais point virgule !
3. passer éventuellement le texte au vérificateur d'orthographe. --> là c'est bon...
En revanche je ne suis pas d'accord avec flo.
En effet, les forums de discussions, comme leur nom l'indique sont là pour que l'on discute, et le discours n'est pas l'écriture !!!!
Paradoxalement, le web nous impose d'écrire pour conserver trace, mais les forums sont bien l'équivalent des discussions du café du commerce, fut-il spécialisé en jus kawatique ou PostGressien !
Bref, je ne voit pas l'intérêt de passer des heures en relecture de sa prose dans ce genre de posts.... Parce que passer au correcteur orthographique des proses entremêlées de code SQL, y'a du sport en perspective. Moi qui écrit des bouquin sur le sujet, je sais bien ce qu'il en coute, et même les correcteurs des maisons d'édition s’arrachent les cheveux !
Enfin, il faudrait que les gens sachent ou se trouvent les caractères majuscules accentuées....
Par exemple dans cet article il y a une faute :
"Evitez les demandes inutiles" devrait être écrit : Évitez les demandes inutiles (accent sur le E majuscule).
A +
Quelles seraient les solutions alors pour obtenir de meilleurs résultats ?
Pré-calculer les résultats ?
Oui, mais comme PostGreSQL ne dispose ni des vues indexées (MS SQL Server) ou des vues matérialisées (Oracle), il faut faire cela à la main par des triggers ce qui est très pénalisant pour les performances et le verrouillage. Pour info SQL Server le fait de manière synchrone, mais en différentiel, ce qui impacte peu les performances. Or reproduire ce type de fonctionnement à la main, par des déclencheurs, est assez complexe...
A +
Le plus performant sera sans doute :
CREATE DOMAIN D_IMEI
AS CHAR(15) --> pas de VARCHAR !
CONSTRAINT CK_IMEI CHECK (CAST(VALUE AS DECIMAL(15,0)) > 0
AND CHARACTER_LENGTH(LTRIM(VALUE)) = 15);;CREATE TABLE T_IMEI
(IMEI D_IMEI);Tests :
Bon :
INSERT INTO T_IMEI VALUES ('123456789012345');Faux et levée d'une exception :
INSERT INTO T_IMEI VALUES ('12345678901234')Taille incorrecte.
INSERT INTO T_IMEI VALUES ('12345678901234a')Lettre incorrecte.
INSERT INTO T_IMEI VALUES (' 23456789012345')Blanc devant
Mais si pour vous les 3 zones de l'IMEI devront être requêtées séparément, alors mieux vaut atomiser dès le départ en 3 colonnes et vous pouvez faire une vue donnant la concaténation.
A +
Je débute en PG, mais on peut faire des transactions DDL ...
Relisez bien ce que j'ai écrit, je parle des transactions dans les routines SQL. Je cite le papier :
[C] Transaction explicites : PostGreSQL ne permet pas de démarrer des transactions explicitement par BEGIN TRANSACTION (ou BEGIN WORK) ni des les terminer (COMMIT, ROLLBACK) dans le code des routines.
Exemple :
CREATE FUNCTION F ()
RETURNS VARCHAR(12)
AS
$code$
BEGIN
create table a (x integer);
insert into a VALUES (1);
SELECT * FROM a;
ROLLBACK TRANSACTION;
end
$code$
LANGUAGE PLPGSQLSELECT F ()ERREUR: la requête n'a pas de destination pour les données résultantes
HINT: Si vous voulez annuler les résultats d'un SELECT, utilisez PERFORM à la place.
CONTEXT: fonction PL/pgsql « f », ligne 6 à instruction SQL
********** Erreur **********
État SQL :42601
A +
La richesse des types de données de PG n'est pas mise en avant.
Par exemple, je suis en train d'évaluer l'utilisation des types intervalle dans notre projet,
et il semble ne pas y avoir de type booléen dans SQL Server 2012.
La comparaison ne portait pas sur les types, mais sur les fonctionnalités.
Il est vrai que le type INTERVAL n'existe pas sous SQL Server.
Cela dit, je trouve ce type épouvantable et il me semble PostGreSQL n'est pas conforme à le norme sur ce point. À me lire :
Le type INTERVAL de SQL et ses dangers
En revanche le booléen est représenté par le type BIT et l'on peut écrire MaColonneBit = true
A +
Bonjour,
Voici une étude comparant les fonctionnalités de Microsoft SQL Server version 2012 et de PostGreSQL version 9.2.
Dans ce comparatif des fonctionnalités de nombreuses sources et explication sont fournies.
http://blog.developpez.com/sqlpro/p1185 … erver-2012
Vos commentaires sont les bienvenus
Sincères salutations
à priori utiliser ST_Intersects....
mais sans autres détails, dont une idée de la structure de votre table et de ses données, difficile de vous aider !
A +
N'auriez vous pas déplacer ou supprimé des fichiers dans le tablespace correspondant à votre base ?
A +
Le snapshot peut se faire, ce n'est pas pour cela que la base sera en état de produire du fait que les opérations de journalisation et les checkpoints sont asynchrone entre fichiers de données et fichier du JT
Si, grâce aux Copy On Write et au fait que PostgreSQL rejouera ces journaux (après restauration) pour gommer toute incohérence dans les fichiers de données.
Vous pouvez toujours espérer... Dans la plupart des cas, cela marchera. Mais si votre serveur était full-up au moment du snapshot, il y a peu de chance que cela marche....
Rien cependant vous oblige de croire une expérience déjà vécue....
Le seul moyen est de "freezer" la base pendant le snapshot, ce qui revient à interdire toute transaction pendant cette opération. Ce que fait VSS pour WVMWare par exemple....
Ce qui à mon sens est parfaitement imbécile, car VMWare est vendue comme solution de haute dispo, dans le but de basculer une VM d'une machine à l'autre. Et pour faire cette haute dispo, le snapshot réalisé sous VSS rend indisponible la base pour les transactions...
A priori, il y a donc quelque chose qui m'échappe : haute dipso rendant indisponible la base...
A +
Un snapshot de base de données fait par un système virtualisé NE PEUT NE AUCUN CAS garantir la bonne restitution de la base, sauf si la base est "offline".
C'est faux. Il est tout à fait possible de faire un snapshot, que ce soit par une fonctionnalité du SAN, du système de fichiers et, pourquoi pas, de la solution de virtualisation.
Le snapshot peut se faire, ce n'est pas pour cela que la base sera en état de produire du fait que les opérations de journalisation et les checkpoints sont asynchrone entre fichiers de données et fichier du JT. Vous avez donc des chances à la restauration du snapshot d'avoir des tables "arrêtées" à la transaction X et le journal arrêté à la transaction Y, et donc au final une base incohérente, du fait de la séquentialité d'enregistrement des fichiers par le mécanisme de snapshot.... D'ailleurs tous les éditeurs de systèmes virtuels déclinent toute responsabilité d'usage pour les SGBDR.... C'est marqué dans les contrat, mais hélas en tout petit. C'est pourquoi des éditeurs comme MS ou Oracle ne garantissent aucunement la virtualisation (sauf pour Oracle sur son propre système virtuel) et demande par exemple de reproduire le bug sur une machine non virtualisé avant toute intervention en garantie....
A +
Bonjour.
J'ai trois tables pour mes tarifs :
Table: prix_nets_sap (+7 millions de lignes)[...]
Et comme à chaque fois que je regarde un explain query, c'est une tannée à comprendre ce qu'il faut faire pour améliorer les choses.
Je vois un Seq scan sur la plus grosse table, alors que j'ai deux index (integer) sur les articles et les clients.
Votre table est obèse et reflète une mauvaise modélisation. En effet, les colonnes se terminant par 1 ou 2 portant le même nom, indique que vous avez dédoublé le nombre de colonne, donc multiplié le volume de données à lire par 2 !
Il aurait fallu simplement rajouter une seule colonne avec la valeur 1 ou 2 pour obtenir le même effet avec des lignes deux fois moins longues, donc un scan déjà deux fois plus rapide. Et si en plus certaines colonnes sont NULL, vous auriez évité de stocker du NULL (le NULL coute cher à stocker !).
En sus il est beaucoup plus facile d'indexer une table avec peu de colonne, qu'une table obèse puisque le nombre d'index potentiel est une factorielle du nombre de colonnes !
À me lire : http://blog.developpez.com/sqlpro/p1007 … es_petites
En sus, avez-vous besoin de toutes les colonnes de P, comme l'indique le p.* du SELECT ?
A +
Merci, c'est bien ce que je craignais...
La perte de perf serait de quel ordre de grandeur ? 10% ? x2 ? x10 ?
On ne cherche pas forcément à être au top et 20% de perte de perf serait acceptable. Si c'est x2, c'est une autre histoire....
Je ne suis pas expert de vmware mais on me dit que, si on utilise les LUN mappés, on se priverai de certaines fonctionnalités de vmware comme les snapshots ou le déplacement de VM. D'un autre côté il me semble que les snapshot sont aussi pénalisants pour les perf. donc pas indiqué pour un SGBD.
Jérôme
Un snapshot de base de données fait par un système virtualisé NE PEUT NE AUCUN CAS garantir la bonne restitution de la base, sauf si la base est "offline". En effet, les écritures entre le journal de transaction et les fichiers de données sont asynchrone. Le snapshot, lui en général est séquentiel. Au final vous vous retrouverez avec une base corrompue.
Seule solution : arrêtez votre base le temps des snapshot des VM ou ne pas utiliser de VM.
De toute façon les VM et les SGBDR c'est franchement pas compatible.
À me lire : SGBDR et virtualisation
A +
> Elle fait quelle taille ? (je dirais entre 1,5 et 2Go vu le plan...
2,4 GO
> Et ça tourne sur quel genre de machine ?
Windows 2003, un serveur de 5 ans d'age. Processeurs Xeon E5420 à 2,5GHz (8 coeurs) et 16 GO de ram. Avec autant de mémoire, la meilleure optimisation des paramètres du serveur serait quoi ?
32 ou 64 bits ?
Si c'est du 32 :
1) vous ne pouvez pas utiliser plus de 4 Go donc 2 sont automatiquement affectés à l'OS.
2) il est possible de faire de la pagination en mémoire haute pour utiliser les 14 Go supplamentaire, mais je ne crois pas que PostGreSQL le supporte (AWE).
A +
Vous avez visiblement un problème de modélisation.
1) vous n'avez pas de PK
2) Vous ne respectez pas la première forme normale par extension (répétition de groupe de colonnes).
Si vous aviez mis une PK à votre table, comme ceci :
ALTER TABLE TEMP ADD PKI SERIAL NOT NULL;
ALTER TABLE TEMP ADD CONSTRAINT PK_TEMP PRIMARY KEY (PKI);et mis vos 16 colonnes Ch1 à Ch16 dans une seule table fille de cette manière :
CREATE TABLE TEMP_COL
(PKI INT NOT NULL ,
NUM_COL SMALLINT NOT NULL,
VAL_COL INT,
CONSTRAINT PK_TEMP_COL PRIMARY KEY (TEMP_COL, NUM_COL));Alors vous auriez eu un modèle normalisé, c'est à dire une vraie base de données et vos temps de réponse auraient été instantanés, grâce à cette requête :
SELECT *
FROM TEMP AS T
WHERE NOT EXISTS(SELECT *
FROM TEMP_COL AS TC
WHERE T.PKI = TC.PKI
AND NUM_COL BETWEEN 1 AND 16);En sus le volume globale de votre base aurait été moindre ! En effet, stocker du NULL coute !!!
A +
Vous utilisez un cas particulier pour démontrer votre point de vue, des cas inverses y en a beaucoup plus...
Tout ça c'est de l'époque pgsql 8.4 non ? car je vois pas ce que pgsql ne peux pas faire dans ce que vous dites et surtout en étant plus cher...
Les vues indexées n'existent toujours pas sous PostGreSQL. Le mirroring synchrone avec basculement automatique n'existe toujours pas (PG Pool nécessite plus de machine et c'est plus du load balancing, et plus de machine, c'est donc plus cher !). Il n'y a toujours pas de mécanisme intégré de réplication des données (quelques tables répliquée d'une base X vers une base Y en transactionnel par exemple) ....
Donc tout cela coute fort cher à implémenter manuellement lorsque l'on a ce besoin et que l'on choisit PostGreSQL....
A +
J'ai du mal avec les comparaisons entre un logiciel gratuit et des logiciels payants (très cher)
Sans doute parce que vous ne savez pas vous y prendre.
Une société qui a un budget de plusieurs centaines de milliers d'euro n'a pas d’intérêt à prendre Postgresql autant prendre du msssql ou de l'oracle, c'est vrai c'est mieux mais c'est plus cher.
Donc dans votre conclusion j'aurais bien aimé voir : si vous n'avez pas 100 000 euros à mettre dans votre serveur de bdd vous pouvez prendre PostgreSQL.
Les choses ne sont pas aussi simple. Le coût des licence est un des choses parmi beaucoup d'autres comme le budget machine ou le temps passée en administration, les logiciels périphériques....
Par exemple dans le cadre du renouvellement du systèmes de gestion des crues du Rhône, auparavant en postGreSQL, l'absence des vues indexées, de la réplication, de la haute dispo et le coût d'administration a vite fait penché la balance en faveur de Microsoft, car il aurait fallut compenser en matériel (faible surcoût) mais surtout en hardware, infrastructure (ligne spécialisée à haut débit) et en logiciels de gestion de la haute dispo très couteux (réplication des IO disque alors que SQL Server dispose du mirroring et de la réplication de données intégrées...) Bref, 2,7 fois plus cher hors coût d'exploitation.
Et en cout d'exploitation, une société spécialisée avait prévue 1 jour par mois d'intervention pour administrer le serveur et les performances.
Après mise en route du système, nous avons fait une seule intervention de contrôle sur demande de la DDE en trois années, pour un système qui est ultra sensible, car simplement vital (24 morts lors des crues de 2002, la DDE ayant été inondé les systèmes, alors sous PostGreSQL, n'étaient plus entièrement opérationnels !). Depuis 2010 le système est redondé en asynchrone sur deux lieux distants de 100 km via SQL Server exclusivement (aucun matériel ni logiciel suplementaire...) malgré une ligne VPN à faible débit...
A +
...
J'aimerais vraiment voir le gain réel de ce genre de "feature".
je n'ai pas poussé mes test assez loin sur une config RAID adéquate par exemple. mais simplement sur mon PC de base, en forçant les écritures finales (CHECKPOINT). Config standard d'installation des deux côtés.
Avec une seule base et les mêmes données, on a déjà une différence de plus de 3 fois plus rapide pour SQL Server.. Une paille !
A +