Vous n'êtes pas identifié(e).
Bonjour,
C'est un sujet un peu compliqué. Le coût estimé d'une requête, c'est vraiment quelque chose qui est estimé à la louche (en partant des statistiques sur les données). Faire baisser le coût, c'est un bon indicateur que c'est probablement mieux, mais pas une preuve absolue, loin de là, malheureusement. Par exemple si il y a une grosse erreur d'estimation (ce qui peut arriver pour plein de raisons… stats insuffisantes, paramètres de la requête un peu hors des valeurs types, nombreuses jointures qui empilent les erreurs d'estimations, etc…), le coût le moins élevé n'est pas forcément le meilleur. Mais bon, on va dire que par défaut, un moindre coût c'est mieux.
C'est pour ça qu'on a les options d'EXPLAIN comme ANALYZE, BUFFERS qui permettent de voir ce qui se passe lors d'une réelle exécution pour comparer
Si vous voulez vraiment comprendre le sujet, la doc explique pas mal de choses, et on trouve maintenant pas mal d'enregistrements de conférences, sur youtube par exemple, sur le sujet.
Les + et espaces ne sont que de la mise en page de psql (vous devez être dans le mode étendu). Ils ne sont pas en base.
Sinon si c'est pour copier d'une base access vers postgres, vous pouvez aussi demander à access de vous produire un CSV. COPY peut importer le format CSV directement, et vous serez sûr de garder vos caractères supplémentaires
Bonjour,
Puisque c'est pour injecter dans un COPY, le plus simple, c'est de remplacer CR par \r et LF par \n. cf paragraphe "Text Format" dans https://www.postgresql.org/docs/current/sql-copy.html
* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
Automatiquement non. Il vous faut un script qui arrête le secondaire une fois qu'il a détecté la déconnexion du secondaire.
Par contre suivant le besoin, une répli synchrone pourrait amener le résultat souhaité… vu qu'on ne peut plus écrire sur le primaire si le standby est déconnecté
En fait ça tombe plutôt bien, on est en plein dans un des cas que wal_level=minimal permet d'optimiser. Si vous mettez le CREATE TABLE et les deux inserts dans la même transaction, là vous ne générerez pas de WAL avec wal_level=minimal. Parce que simplement vérifier que la table est écrite sur le disque à la fin de la transaction (un sync des fichiers qui la composent) suffit (si PG crashait entre temps, il suffirait d'effacer ces fichiers au redémarrage).
Mais en vrai, il y a peu de cas où on gagne vraiment avec minimal. Il faut vraiment connaître ces quelques cas particuliers pour en profiter
Vous pouvez essayer l'option -j de pg_dump, pour paralléliser le dump (plusieurs tables en parallèle). Vous n'aurez de gros gains avec cette méthode que si vous quelque chose de parallélisable évidemment, donc pas une grosse table unique dans la base.
Il me semble oui, mais regardez la doc sur ALTER TABLE, c'est assez détaillé
exactement. C'est le critère qui met en correspondance les enregistrements des deux tables.
Le select 1 est en fait juste une "astuce" d'écriture. Le not exists vérifie juste que la sous-requête retourne un enregistrement. Son contenu n'a absolument aucune importance. J'ai pris l'habitude de l'écrire comme ça parce que pour le relecteur éventuel de la requête, c'est comme ça évident que le contenu de la sous-requête ne sert à rien. Ça pourrait être select 0 ou select 'toto' ça marcherait exactement pareil
Vous avez tous les index qui doivent être là sur la partition finale ? Comme le dit la doc, "This form attaches an existing table (which might itself be partitioned) as a partition of the target table. The table can be attached as a partition for specific values using FOR VALUES or as a default partition by using DEFAULT. For each index in the target table, a corresponding one will be created in the attached table; or, if an equivalent index already exists, it will be attached to the target table's index, as if ALTER INDEX ATTACH PARTITION had been executed". Donc si il manque des index, ils vont être créés au moment de l'ALTER TABLE, alors que vous pourriez les avoir pré-créés (éventuellement en CONCURRENTLY, je ne connais pas votre cas d'utilisation).
Il peut aussi se retrouver à faire une vérification de votre "FOR VALUES" si il n'y a pas de contrainte CHECK sur la partition au moment de l'ATTACH: "If the new partition is a regular table, a full table scan is performed to check that existing rows in the table do not violate the partition constraint. It is possible to avoid this scan by adding a valid CHECK constraint to the table that allows only rows satisfying the desired partition constraint before running this command. The CHECK constraint will be used to determine that the table need not be scanned to validate the partition constraint. This does not work, however, if any of the partition keys is an expression and the partition does not accept NULL values. If attaching a list partition that will not accept NULL values, also add NOT NULL constraint to the partition key column, unless it's an expression."
Ou un NOT EXISTS si c'est simplement pour un test d'existence. le NOT IN est plus dangereux: il peut y avoir des NULL dans la seconde liste, alors il y a des optimisations qui pourraient ne pas être faisables. Le LEFT JOIN risque de vous dupliquer les enregistrements s'ii y en a plus d'un qui correspond
Quelque chose du genre
SELECT * from t1 where NOT EXISTS (SELECT 1 FROM t2 where t1.a=t2.a)Ça a l'air bon. Vous êtes sûr de votre mot de passe ? Sinon, vérifiez aussi qu'il est bien stocké en scram et pas en md5 dans le catalogue (regardez dans pg_shadow, si le champ passwd commence bien par SCRAM)
Je ne connais pas R. Par contre le message d'erreur, c'est la librairie libpq (celle qu'on utilise à peu près tous, en C) qui vous dit que l'authentification par mot de passe (donc dans le fichier pg_hba.conf une ligne password, md5, ou scram)… le dernier étant recommandé. Vous êtes sûr du mot de passe ?
Attention quand même, si ce trigger peut être déclenché par un autre trigger (par exemple parce qu'un autre trigger peut mettre à jour cette table), pg_trigger_depth() ne va pas faire ce que vous espérez. C'est la profondeur totale de triggers, pas le nombre d'appels récursifs de ce trigger seulement.
Une des possibilités est d'utiliser la fonction pg_trigger_depth() (https://www.postgresql.org/docs/14/functions-info.html). Si on peut garantir que ce trigger ne peut pas être déclenché par un autre trigger que par lui-même, ça suffit (ça a toujours été le cas pour moi).
Sinon, si on ne peut pas garantir ça, je pense qu'il faut utiliser https://www.postgresql.org/docs/current … CALL-STACK , et analyser la pile d'appel pour savoir si le trigger a été appelé par lui-même. Mais c'est sale, c'est de l'analyse de chaîne de caractères…
Ça veut dire que sur un moteur MVCC, un SELECT ne va pas bloquer un INSERT/UPDATE/DELETE, et l'inverse non plus. Seuls deux ordres de modification de données peuvent entrer en conflit (et les alter table, lock table, etc… évidemment). Les moteurs non-MVCC résolvent le problème avec d'autres méthodes, comme le NOLOCK. C'est un compromis différent.
le with nolock de sql server, c'est pour éviter le verouillage des enregistrements lors du select (et surtout pouvoir lire des enregistrements qui sont verrouillés, et donc pourraient être en cours de mise à jour). PostgreSQL fonctionne un peu différemment là-dessus, cf https://www.postgresql.org/docs/current/mvcc-intro.html
OK. C'est mal ! 
Plus sérieusement, sans PK, on peut accéder les enregistrements par leur CTID…
WITH candidates AS (SELECT ctid, art_id,
prix,
maj,
ROW_NUMBER() OVER(PARTITION BY art_id,
maj
ORDER BY maj,prix DESC) AS DuplicateCount
FROM historique_prix WHERE art_id = 6739),
to_delete AS (SELECT ctid FROM candidates WHERE DuplicateCount > 1)
DELETE FROM historique_prix WHERE ctid IN (SELECT ctid FROM to_delete)Le problème, c'est qu'un update d'un enregistrement peut changer son CTID (c'est leur adresse physique dans la table). Donc cet ordre SQL pourrait ne pas marcher si il y a des mises à jour concurrentes des enregistrement qu'on veut nettoyer
Bonjour, pas moyen de retrouver les enregistrements comme ça. Il y a une PK à la table ?
Parce que si oui, vous pouvez certainement réécrire ça de la sorte:
WITH candidates AS (SELECT ma_pk, art_id,
prix,
maj,
ROW_NUMBER() OVER(PARTITION BY art_id,
maj
ORDER BY maj,prix DESC) AS DuplicateCount
FROM historique_prix WHERE art_id = 6739),
to_delete AS (SELECT ma_pk FROM candidates WHERE DuplicateCount > 1)
DELETE FROM historique_prix WHERE ma_pk IN (SELECT ma_pk FROM to_delete)Les 25 milliards, c'est les "25 milliards d'enregistrements que le nœud a produits", dont la plupart sont ensuite supprimés par le join filter. J'imagine que c'est parce qu'il est obligé de produire ses enregistrements plusieurs fois pour le merge join, si on a n-n id_marque qui correspondent . Pour supprimer le materialize, tu peux essayer de désactiver enable_materialize juste avant d'exécuter cette requête. J'ai déjà eu des environnements où désactiver materialize sur des requêtes apportait de meilleurs résultats... maintenant que j'y repense, la dernière fois, ça devait être une 9.6
Très bonne nouvelle.
J'imagine que vous mettez à jour
c'est bizarre, c'est exactement ce que vous deviez faire. On dirait un problème di'nterprétation de la ligne de commande. Essayez de virer le \ juste avant le ", avant le start. Je n'ai aucune idée de comment l'interpréteur de commande de windows va réagir à ça. On dirait que pg_ctl n'a pas vu l'opération start. Comme si pour lui l'option -D l'avait englobé par exemple.
Je pense que vous allez avoir beaucoup de mal à la trouver. La version 8.1 est morte et enterrée depuis longtemps. Ça fait 12 ans qu'elle n'est plus supportée. Si vous ajoutez à ça que les versions windows ont toujours été fournies par une entreprise (EDB), pas par la communauté elle même comme les versions Linux.
Vous avez peut-être plus de chance de réussir à la faire tourner en récupérant aussi le répertoire de postgresql dans le program files de votre machine et en essayant de l'exécuter tel quel (à coup de pg_ctl je pense)
Bonjour,
Comment on considère que plusieurs entrées de carpooling_proofs correspondent au même trajet d'un conducteur ? Parce que là on peut imaginer qu'un conducteur prenne un passager à 14h, un autre à 15h, tous les deux sur le même trajet, et un autre à 17h sur le trajet retour?
Je pense que c'est clientcert=verify-full que vous voulez (cf https://www.postgresql.org/docs/current/ssl-tcp.html)