Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
Je suis tout débutant en Postgresql donc il doit avoir des choses que je n'ai pas faites .
J'ai une table avec deux champs sans aucun index avec actuellement 1 554 138 lignes , quand je veux mettre un index sur un champ j'ai le message d'erreur suivant :
"ERREUR: la ligne index requiert 1298240 octets, la taille maximum est 8191".
D'autre part à partir d'une table vide sans index quand j'ai voulu importer un fichier .csv avec 2 902 593 lignes il a été importer que 1 554 138 lignes sans message d'erreur , bizarre non .
Texte de mon SQL : COPY nom(id,nom_art) FROM '/home/notill/xaa_8.csv' DELIMITER ',' CSV ;
A la création d'une table y a t'il des limites à lever ?
J'ai fait tout ça à partir de pgadmin4 , Postgresql 12.1 .
Merci d'avance pour les réponses .
Hors ligne
"ERREUR: la ligne index requiert 1298240 octets, la taille maximum est 8191".
=> Vous avez des champs trop gros pour être indexés. J'imagine que c'est une chaîne de caractères que vous essayez d'indexer ? Si oui, il y a une limite (elle est même plus basse en fait). On a quelques moyens de contournement, mais c'est à voir dans un second temps.
D'autre part à partir d'une table vide sans index quand j'ai voulu importer un fichier .csv avec 2 902 593 lignes il a été importer que 1 554 138 lignes sans message d'erreur , bizarre non .
Non, pas forcément, on peut très bien avoir des retours de chariots dans un CSV. Un enregistrement de ce genre par exemple:
1;"bonjour
les copains"
2;toto3 lignes, 2 enregistrements.
Marc.
Hors ligne
Compris pour les index , en fait mon champ peut contenir plus 40 caractères .
.
Pour le fichier .csv ( je suis sur Linux ) quand je l'ouvre avec GEANY , normalement une ligne un enregistrement avec pour chaque ligne le champ 1 puis la virgule puis le champ 2 puis le caractère \n LF .
Et j'ai bien 2 902 593 lignes , après dans le champ 2 j'ai des caractères non ASCII cela peut'il poser problème .
Hors ligne
J'imagine que ce n'est pas 40 caractères (soit maximum 160 octets en utf8), mais une faute de frappe ?
Pour le fichier CSV, vous êtes sûr d'avoir vérifié l'intégralité des lignes ?
Les caractères non-ascii ne posent pas de problème, tant que l'encodage de votre fichier est le même que celui de la session (ou que vous avez passé l'encoding à COPY). Vous pouvez voir l'encoding de la session avec SHOW client_encoding... aucune idée de ce que fait pgadmin4 de ce point de vue...
Marc.
Hors ligne
Pour le csv je regarde ça de plus près , à mon avis plus de 1 400 000 lignes qui manque cela doit se voir !!!! ou s'expliquer assez simplement .
Malheureusement je ne peux pas l'ouvrir dans un tableur , je vais regarder cela avec Python .
Je fais de l'informatique ,de la base de données en amateur donc rien d'urgent , encore merci de m'avoir répondu .
Hors ligne
Après quelques manipulations voila ce que je constate .
Comptage du nombre de lignes avec Python du fichier csv :2 902 297
Insertion avec du code python du fichier csv dans une table Postgres , c'est à dire balayage du fichier ligne par ligne avec requête insert à chaque ligne et comptage des enregistrements ( ça ma quand même pris plusieurs heures )
Python à compter 2 902 297 enregistrements , quand je fait COUNT sur la table on a 2 902 297 lignes , donc tout va bien
Quand je rentre le même fichier CSV avec une requête SQL commande COPY , j'ai avec COUNT sur la table 1 554 136 lignes , mais quand j'exporte ma table en fichier CSV , le fichier résultant à 2 902 297 lignes , étonnant non .
J'ai fait ça pour plusieurs fichiers et à chaque fois , quand j'importe avec COPY je n'ai pas le même nombre de lignes dans la table et le fichier CSV .
Bon sur ce , je vais passer à autre chose .
Hors ligne
le fichier résultant à 2 902 297 lignes , étonnant non .
Pas plus que ça, puisque comme l'a écrit Marc plus haut, le nombre de lignes d'un fichier CSV peut être supérieur au nombre d'enregistrements, vu qu'un enregistrement peut s'étaler sur plusieurs lignes.
Le format CSV est décrit ici: https://tools.ietf.org/html/rfc4180
et Postgres suit à peu près cette spécification, sauf pour le CRLF de fin de ligne qui peut être un LF seul.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
J'ai trouvé l'explication , en fait dans mon fichier csv j'avais 8 champs texte qui commençait par un guillemet unique , quand je fais COPY lors du balayage Postgresql trouve le premier guillemet et cherche ensuite le second , une fois trouvé il met tout ça ensemble ce qui fait que à partir d'un fichier csv qui a des champs avec quelque dizaines de caractères , je me retrouve avec 4 champs qui ont plusieurs millions de caractères , ce qui explique l'indexation impossible et la disparition de plusieurs milliers de lignes et que quand Postgresql exporte la table en csv on retrouve le nombre de lignes car il a conservé le caractère LF .
En fait c'est ce que j'ai cru comprendre .
Hors ligne
Effectivement si le CSV est généré sans considérer le guillemet comme un caractère spécial, ça peut produire ce genre de problème. Et c'est assez plausible parce que pas mal de générateurs sont baclés en 3 lignes de code sans se soucier de cette règle ou des champs multilignes.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1