Discussion :

[MATTASOGLIO]

Bonjour

Je suis en postgres 15.17
impossible de comprendre pourquoi cela ne fonctionne pas
si quelqu'un a une idée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
drop table dberdlb2;
CREATE TABLE dberdlb2 (
    printdoc varchar(36) NOT NULL
) 
PARTITION BY RANGE (printdoc) ;
 
CREATE TABLE dberdlb2_140000000000   partition of  dberdlb2 FOR VALUES FROM ('140000000000')  TO ('149999999999');
CREATE TABLE dberdlb2_1490000000000  partition of  dberdlb2 FOR VALUES FROM ('1490000000000') TO ('1499999999999');

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
orp=# drop table dberdlb2;
DROP TABLE
orp=# CREATE TABLE dberdlb2 (
orp(#     printdoc varchar(36) NOT NULL
orp(# )
orp-# PARTITION BY RANGE (printdoc) ;
CREATE TABLE
orp=# CREATE TABLE dberdlb2_140000000000   partition of  dberdlb2 FOR VALUES FROM ('140000000000')  TO ('149999999999');
CREATE TABLE
orp=# CREATE TABLE dberdlb2_1490000000000  partition of  dberdlb2 FOR VALUES FROM ('1490000000000') TO ('1499999999999');
ERROR:  partition "dberdlb2_1490000000000" would overlap partition "dberdlb2_140000000000"
LINE 1: ...00000000  partition of  dberdlb2 FOR VALUES FROM ('149000000...

Bien a vous

[escartefigue]

Bonjour,

Le message est pourtant clair : les valeurs des bornes de partitionnement provoquent un chevauchement.
En effet la valeur de la borne de fin de la première partition est supérieure à la valeur de la borne de début de la deuxième.

De plus, votre table ne comporte qu'une seule colonne de type varchar, visiblement aucune PK, ou alors le script est incomplet et la PK est cette colonne unique.
Si c'est le cas, il faut savoir que le type varchar est ce qu'on peut faire de pire pour une PK :

• les types char et varchar contiennent le plus souvent des valeurs sémantiques et de ce fait instables, or, une PK se propage dans les tables liées au travers des contraintes d'intégrité.
  Ce faisant, toute mise à jour de la PK provoque des mises à jour en cascade qui pénalisent les performances ;
• à nombre de valeurs égal, l'encombrement d'un type char ou varchar est beaucoup plus important que celui d'une colonne de type integer, ce qui pénalise aussi les performances ;
• le char et le varchar sont sensibles à la collation ;
• le varchar requiert un alignement sur une longueur fixe pour les comparaisons ;
• le varchar provoque des déplacements des pages data et index quand le contenu change en longueur effective, ce qui provoque une fragmentation (désorganisation), là aussi au détriment des performances.

Il serait donc préférable d'ajouter une PK de type integer (voire BIGINT si besoin) avec la propriété IDENTITY.

[MATTASOGLIO]

Bonjour

la table est simplifiée au maximum pour une compréhension facile

Les partitions ne se chevauchent pas
140 000 000 000 149 999 999 999
1 490 000 000 000 1 499 999 999 999

Si tout était en bigint il n'y aurait pas de pb
mais evidement je n'ai pas tellement le choix

merci tout de même pour la réponse

[escartefigue]

Vu que le type est varchar, il y a bien chevauchement : le tri se fait de façon alphabétique, de gauche à droite
Si le type était numérique, il n'y aurait pas de chevauchement.

[MATTASOGLIO]

Bonjour

c'est bien cela

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
drop table dberdlb2;
CREATE TABLE dberdlb2 (
    printdoc varchar(36) NOT NULL
) 
PARTITION BY RANGE (printdoc) ;
 
CREATE TABLE dberdlb2_140000000000   partition of  dberdlb2 FOR VALUES FROM ('000140000000000')  TO ('000149999999999');
CREATE TABLE dberdlb2_1490000000000  partition of  dberdlb2 FOR VALUES FROM ('001490000000000')  TO ('001499999999999');

Merci

[escartefigue]

Mais pourquoi choisir un varchar si cette colonne ne contient que des valeurs numériques ?
Un type integer voire bigint si nécessaire serait autrement plus concis et plus performant.