Discussion :

[SQLpro]

...
Voici la nouvelle fonctionnalité dont estofilo parle, et qui arrivera pour la 9.2: index-only-scans.
C'était clairement un manque cruel de Postgres, on est d'accord. C'est dommage toutefois d'appuyer cet argument avec cet exemple précis, car il est connu que Postgres ne sait pas utiliser uniquement une lecture d'index pour lire des données (d'où un fullscan pour un SELECT count(*) sur une table).
Pour ma part, j'aurai aimé que vous donniez un exemple plus "pertinent". Pertinent dans le sens où vous mettez vraiment en défaut l'optimiseur de Postgres sur un cas qu'il est censé pouvoir traiter correctement.

Ce serait avec joie... J'en ais plein !
Le seul problème est que les requêtes sont déjà complexe et que les erreurs de plan le sont avec au moins 5 à 6 tables dans la requête et une certaine volumétrie.
Là le format des blogs ne me permet pas de le faire et surtout cela aurait brouillé complément le reste du texte.

Je citais un exemple d'une collectivité local ou il a fallut de débarrasser de PG au profit de SQL Server.
L'éditeur de l'époque que ne ne citerais pas, mais qui est quand même dans les témoignages a été jusqu'à affirmer que le problème c'était PG et qu'il fallait s'en débarrasser au profit de fichiers plats, cela irait beaucoup plus vite !
C'est à cette époque que l'on m'a contacter pour renouveler le système.
J'ai effectivement vu quels étaient les problèmes des requêtes et compte tenu de la volumétrie et de la complexité de certaines requêtes, certains plans de PG étaient catastrophiques. Ce pourquoi il a été abandonné entre autres (et aussi parce que pas de vues indexées, pas de haute dispo digne de ce nom...)

A +

[frost242]

Mais ça ne veut rien dire. Tous les SGBDR aussi reposent sur un OS et peuvent utiliser un SAN du RAID et tout le toutim exactement dans les mêmes conditions que PG le fait. Mais EN PLUS ils permettent de gérer administrativement et techniquement les espaces de stockage.
Donc dans PG, il n'y a aucune gestion intégrée des espaces de stockage propre aux bases du SGBDR !

Cela vous gène terriblement. Pour ma part, je fais avec et fais en sorte de ne pas être pénaliser par un manque d'espace de stockage par exemple - je mets donc en place la supervision de cet espace de stockage.
Connaissant assez bien Oracle tout de même, je vous rejoints sur les avantages de ce système.

D'un point de vu système ce que vous dites est vrai. Mais c'est vrai aussi sur n'importe quel OS, Windows compris...
MAIS, cela n'apporte pas grand chose pour le SGBDR.
Je vous donne un seul exemple (c'est d'ailleurs lié au parallélisme des requêtes que PG ne sait pas gérer)...

Je comprends donc ce point de vue lorsque vous l'associez au parallélisme.

La chance et la malchance veut que PG ait organisé son système de stockage par de multiples fichiers (en gros une table est un fichier).
L'OS peut donc savoir quels fichiers vont être impacté par une mise à jour des données. Il me semble qu'il lui est en revanche impossible de savoir quelle page dans le fichier doit être impactée.

Je ne vous suis pas. L'OS sait quelles sont les pages impactées car les écritures se font au niveau de la page. Vous ne réécrivez pas le fichier dans son intégralité, et l'OS sait donc parfaitement se débrouiller pour redistribuer les écritures.

Avez vous travaillé avec des grandes volumétries et comparé les temps de réponse de PG par rapport à du Oracle ou du SQL Server. Je citais un exemple d'un collectivité local ou il a fallut de débarrasser de PG au profit de SQL Server pour un cas doublement critique : forte volumétrie (et exigence d'un temps de réponse rapide) et haute dispo, pour un système de gestion de catastrophes naturelles extrêmement sensible.

Je n'ai pas travaillé sur des volumétries très fortes (200Go max, mais mauvais temps de réponses dû à une mauvaise modélisation).
En revanche, pour traiter la problématique de haute-disponibilité, j'ai utilisé du Red Hat Cluster Suite qui est simple et efficace - le service bascule en moins d'une minute. Je suis donc passé par un outil externe.

Je ne crois pas. VACUUM FULL fait un verrou exclusif de la table entière. Le mécanisme n'est pas décrit en détail pour les autres options, mais vu qu'il ne parle pas de snapshot, je suppose qu'il verrouille page par page, ce qui est effectivement moins contraignant mais génère une IO par page, d'où la remarque "VACUUM causes a substantial increase in I/O traffic, which might cause poor performance for other active sessions"
Là encore le choix de conception de la non gestion des espaces de stockage comme l'absence de // se fait sentir.
Pour info, SQL Server utilise un snapshot pour l'analyse (donc aucun verrou d'aucune sorte) et permet de reconstruire les index en parallèle, ce qui fait que les utilisateurs peuvent continuer d'utiliser l'ancienne version de l'index, la nouvelle remplaçant l'ancienne une fois la reconstruction terminée. Le tout étant fait en //

Je crois que l'on ne se comprend pas.

Encore une fois, je le redis: VACUUM ne pose pas de verrou. Mais oui, VACUUM FULL pose un verrou exclusif. Il faut faire un gros distinguo entre ces deux opérations: la première - VACUUM - est nécessaire, consommatrice d'I/O mais ne va pas impacté les transactions. La seconde - VACUUM FULL - est à éviter dans la mesure du possible.

En gros, VACUUM va scanner l'ensemble des pages de la table et déterminer si la page peut être réutilisée. Si c'est le cas, elle va être inscrite dans la "free space map". Les blocs seront par la suite réutilisés pour d'autres écritures.

A contrario, VACUUM FULL va défragmenter la table (et pourrir les index qu'il faudra reconstruire). Jusqu'à la 8.4, c'est une opération très lourde et je rejoints d'ailleurs scheu sur ce point: on va souvent plus vite à réimporter une table qu'à faire un VACUUM FULL. A partir de la 9.0, cette opération a été ré-implémenté et réalise maintenant une copie toute propre de la table, ce qui est bien plus efficace mais nécessite un espace disque suffisant.

Pour ce qui est de la reconstruction des index, ce n'est pas VACUUM et VACUUM FULL qui la traite (ou peut-être pour le "nouveau" VACUUM FULL de la 9.0, mais je n'y mettrai pas ma main à couper). Vous utilisez REINDEX qui va poser un verrou exclusif sur la table ou bien vous rusez un peu et vous faites à la main ce que SQL Server fait tout seul: vous créez un nouvel index identique avec l'ordre CREATE INDEX CONCURRENTLY - opération non-bloquante - et lorsqu'il est créé, vous détruisez l'ancien index et renommez le nouveau pour qu'il porte le bon nom.

Edit: j'ai vu l'article du blog après. OK. Il pose des verrous, mais néanmoins: "a VACUUM does not block an UPDATE". J'en reste surtout sur ce dernier point. Merci pour ce lien.

[frost242]

Ce serait avec joie... J'en ais plein !
Le seul problème est que les requêtes sont déjà complexe et que les erreurs de plan le sont avec au moins 5 à 6 tables dans la requête et une certaine volumétrie.
Là le format des blogs ne me permet pas de le faire et surtout cela aurait brouillé complément le reste du texte.

Si l'on a l'occasion de se croiser, je serai assez intéressé. Si vous avez le temps de faire remonter ces problèmes, les développeurs du Postgres seraient content de votre retour.

Je citais un exemple d'une collectivité local ou il a fallut de débarrasser de PG au profit de SQL Server.
L'éditeur de l'époque que ne ne citerais pas, mais qui est quand même dans les témoignages a été jusqu'à affirmer que le problème c'était PG et qu'il fallait s'en débarrasser au profit de fichiers plats, cela irait beaucoup plus vite !
C'est à cette époque que l'on m'a contacter pour renouveler le système.
J'ai effectivement vu quels étaient les problèmes des requêtes et compte tenu de la volumétrie et de la complexité de certaines requêtes, certains plans de PG étaient catastrophiques. Ce pourquoi il a été abandonné entre autres (et aussi parce que pas de vues indexées, pas de haute dispo digne de ce nom...)

Par curiosité, c'était avec quelle version de Postgres ? Une version plus récente aurait forcément fait mieux, mais je me souviens avoir dû bidouiller pas mal des requêtes en version 8.0.

Très fort le coup du fichier plat ! J'ai aussi eu le coup des index qui sont inutiles car ils pénalisent les écritures

[scheu]

C'est pour cela qu'il est vivement recommandé de ne pas utiliser VACUUM FULL. Et en plus il pourrie les index au passage, qu'il faudra donc reconstruire par la suite.

En revanche, VACUUM est vivement recommandé pour pouvoir réutiliser l'espace "mort" - l'espace laissé par des lignes mortes.

Le problème du vacuum full c'est qu'il ne récupère pas l'espace disque physiquement. Une table de 100 Go qui a été purgée à 90% de ses lignes fera toujours 100 Go sur disque (et non pas 10 Go si j'arrondis grossièrement).
Le seul moyen de récupérer l'espace et de faire un export puis drop/truncate puis import

Alors que sur Oracle par exemple tu peux faire un "alter table <matable> move;"

Pour les indexes, problème similaire : commment récupérer l'espace disque sur des gros indexes dont la table a été purgée à 90% ?
Postgresql n'a pas de notion de "rebuild". Il faut supprimer puis recréer l'index ce qui est très couteux sur de grosses tables et peut même mettre en péril la cohérence des données si on supprime temporairement des PK pour les recréer

[frost242]

@scheu: normalement l'espace est récupéré pour de bon à partir de la 9.0. Ce serait étonnant que ça ne soit pas le cas. Donc attention, je parle des versions très récentes de PG.
Et pour reconstruire les index, tu n'as pas d'option REBUILD c'est vrai. Vous utiliserez l'ordre REINDEX pour le reconstruire. avec REINDEX.

Pour vérifier la nouvelle implémentation de VACUUM FULL en 9.1 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
big=# SELECT version();
                                                  version                                                   
------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2, 64-bit
(1 ligne)
 
big=# CREATE TABLE t (i INTEGER PRIMARY KEY);
NOTICE:  CREATE TABLE / PRIMARY KEY créera un index implicite « t_pkey » pour la table « t »
CREATE TABLE
 
big=# INSERT INTO t SELECT generate_series(1, 1000000);
INSERT 0 1000000
                               ^
big=# SELECT pg_table_size('t');
 pg_table_size 
---------------
      36282368
(1 ligne)
 
big=# DELETE FROM t WHERE i > 100000
big-# ;
DELETE 900000
big=# SELECT pg_table_size('t');
 pg_table_size 
---------------
      36290560
(1 ligne)
 
big=# VACUUM FULL t;
VACUUM
big=# SELECT pg_table_size('t');
 pg_table_size 
---------------
       3629056
(1 ligne)

Pour preuve, ce qu'il y a au niveau OS:

Code :

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

1
2
3
4
5
6
7
8
9
 
big=# SELECT relname, relfilenode FROM pg_class WHERE relname = 't';
 relname | relfilenode 
---------+-------------
 t       |       24618
(1 ligne)
 
# ls -l base/base/24612/24618
-rw------- 1 oam oam 3629056 2011-10-13 12:50 24618

[scheu]

@frost242
J'ai l'habitude de gérer des bases Postgresql de 100 Go environ, et le REINDEX n'est pas une solution viable pour récupérer l'espace, car il locke la table

Le VACUUM FULL est-il vraiment beaucoup plus rapide dans les dernières versions ? Si c'est pour mettre 30 minutes plutôt que 3 heures sur une table de 10 Go c'est déjà trop pour moi

Bref je ne dénigre pas Postgresql loin de là, mais je constate simplement que, comme déjà dit dans mon premier message, pour des grosses volumétries à traiter il y a encore beaucoup de contraintes, quand on est sur un environnement de production haute-dispo où les tables et données doivent être accessible 24h/24 sans verrous ni recréation d'indexes ni export/imports

C'est un peu comme le partitionnement ou les pseudos-paramètres remplaçant les hints : entre dire d'un côté "la fonctionnalité existe sur Postgresql" ou "on peut se débrouiller différemment en faisant comme ça", et de l'autre côté la pratique et la réalité sur des gros environnements en entreprises, il y a encore une montagne.
A titre personnel en tout cas, je maintiens mon sentiment initial qui est que Postgresql ne peut pas (encore) remplacer un SGBD payant sur des applications volumineuses ou critiques (données accessibles 24h/24 sans verrous) ou complexes (requêtes dépassant les 4-5 jointures)
Alors que Postgresql fait très bien l'affaire dans les cas inverses

[CinePhil]

Ce dernier point m'inquiète un petit peu :

Postgresql ne peut pas (encore) remplacer un SGBD payant sur des applications volumineuses ou critiques (données accessibles 24h/24 sans verrous) ou complexes (requêtes dépassant les 4-5 jointures)

Je vais mettre en oeuvre une BDD personnelle et, sans avoir de gros volumes de données à traiter, quelques dizaines de milliers de lignes au plus, 4 ou 5 jointures dans une requête, ce sera sans doute assez fréquent.

Postgresql devient vraiment un escargot avec aussi peu de jointures ?

[frost242]

@frost242
J'ai l'habitude de gérer des bases Postgresql de 100 Go environ, et le REINDEX n'est pas une solution viable pour récupérer l'espace, car il locke la table

Le VACUUM FULL est-il vraiment beaucoup plus rapide dans les dernières versions ? Si c'est pour mettre 30 minutes plutôt que 3 heures sur une table de 10 Go c'est déjà trop pour moi

Concernant la vitesse du nouveau VACUUM FULL, je ne sais vraiment pas vous répondre, nous en sommes encore à la version 8.4. Donc je n'ai vraiment pas d'expérience dessus.

Je me cite d'un message précédent, il y a une alternative à REINDEX:

Vous utilisez REINDEX qui va poser un verrou exclusif sur la table ou bien vous rusez un peu et vous faites à la main ce que SQL Server fait tout seul: vous créez un nouvel index identique avec l'ordre CREATE INDEX CONCURRENTLY - opération non-bloquante - et lorsqu'il est créé, vous détruisez l'ancien index et renommez le nouveau pour qu'il porte le bon nom.

C'est disponible à partir de la 8.2. En revanche, il faut gérer les éventuelles contraintes, comme ceci:

Code :

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

1
2
3
4
5
6
 
 =# CREATE UNIQUE INDEX CONCURRENTLY idx_pk2 ON test_pk (a);
 =# BEGIN ;
 =# ALTER TABLE test_pk DROP CONSTRAINT idx_pk;
 =# ALTER TABLE test_pk ADD primary key using index idx_pk2;
 =# COMMIT ;

source: Quoi de neuf dans PostgreSQL 9.1.

[scheu]

Je me cite d'un message précédent, il y a une alternative à REINDEX:

C'est disponible à partir de la 8.2. En revanche, il faut gérer les éventuelles contraintes, comme ceci:

Code :

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

1
2
3
4
5
6
 
 =# CREATE UNIQUE INDEX CONCURRENTLY idx_pk2 ON test_pk (a);
 =# BEGIN ;
 =# ALTER TABLE test_pk DROP CONSTRAINT idx_pk;
 =# ALTER TABLE test_pk ADD primary key using index idx_pk2;
 =# COMMIT ;

Effectivement je n'avais pas lu le message précédent. Je ne connaissais pas cette nouveauté, merci

[scheu]

Ce dernier point m'inquiète un petit peu :

Je vais mettre en oeuvre une BDD personnelle et, sans avoir de gros volumes de données à traiter, quelques dizaines de milliers de lignes au plus, 4 ou 5 jointures dans une requête, ce sera sans doute assez fréquent.

Postgresql devient vraiment un escargot avec aussi peu de jointures ?

Quelques dizaines de milliers de lignes, ce n'est pas beaucoup de volumétrie. a moins d'avoir un serveur peu performant Postgresql devrait faire l'affaire sans problème
Quand je parle des problèmes que je rencontre, je parle personnellement de tables de plusieurs Go et de plusieurs millions de lignes

Les requêtes ayant beaucoup de jointures sont peu performantes sous Postgresql car l'optimiseur aura beaucoup de mal à trouver un plan d'exécution correct. J'insiste à nouveau particulièrement sur le point ci-dessous que je rencontre très souvent :

Ca arrive encore trop souvent que les plans d'exécution soient pourris sur Postgresql (même avec des stats à jour et des indexes bien placés) dès qu'on a des requêtes un peu complexes (jointure entre 6-7 tables, auto-jointures, sous-jointures, ...), ou comportant trop de colonnes filtrées sur les tables

Le principal défaut est qu'il sous-estime trop souvent les cardinalités (nombre de lignes retournées à chaque étape du plan), ce qui conduit au bout d'un moment :
- soit à lui faire choisir des "nested loop" au lieu de "hash join" en cas de jointure
- soit à des "index range scan" trop coûteux alors qu'un full scan de la table serait au final meilleur
Je pense que ce problème est lié au fait que Postgresql sait très mal évaluer les nombres de lignes retournés pour des filtres qui comportent plusieurs colonnes
Là où Oracle ou SQL Server, sur un index (col1,col2,col3), sait faire des stats dessus et savoir estimer, pour chaque valeur du triplet, le nombre de lignes dans la table, Postgresql ne sait le faire que dans de très rares cas, les histogrammes se limitant sur des colonnes uniques et pas des t-uples

Mais même avec des plans d'exécution peu optimisés, la faible volumétrie "masquera" les problèmes éventuels. L'idéal si tu veux en être certain serait de pouvoir tester ton application dans un environnement de pré-production, à volumétrie et à requêtes comparables

[SQLpro]

CREATE INDEX CONCURRENTLY - opération non-bloquante - et lorsqu'il est créé, vous détruisez l'ancien index et renommez le nouveau pour qu'il porte le bon nom.

ça c'est ce qui existe che SQL Server avec le CREATE INDEX ... DROP EXISTING. depuis 1998...

Mais c'est toujours au final une création d'index....

Par exemple chez SQL Server on peut directement défragmenter un index sans que les utilisateurs ne constate de blocage ni de gros ralentissement.
DBCC INDEXDEFRAG (depuis 1998 aussi).
Et effectivement en pratique 95% de la place perdu est récupérée.

A +

[estofilo]

La copie de fichier n'a rien à voir avec une sauvegarde digne de ce nom puisqu'il est impossible de copier des fichiers à chaud alors que la base travaille.... En principe point n'est besoin d'arrêter une base ou un serveur pour effectuer une sauvegarde.

Non je parlais bien d'une sauvegarde consistante à chaud sans arrêter la base.
La procédure pour ça est:

SQL> select pg_start_backup(...);
...
sauvegarde au niveau système de fichiers par un outil externe (rsync, tar, cp,...)
...
SQL> select pg_stop_backup();

Entre le pg_start_backup() et le pg_stop_backup() postgres s'arrange pour maintenir les fichiers de données dans un état consistant.
C'est la technique de base pour faire ensuite "Point In Time Recovery" ou pour initialiser un serveur esclave pour la réplication par log shipping.

ça ce sont des sauvegardes du journal de transaction. Rien à voir avec des sauvegardes différentielles. Les sauvegardes différentielles sauvegardent les pages de données qui ont été modifiées depuis un certain temps (une sauvegarde précédente).
Lisez par exemple ceci pour comprendre les différences : http://fr.wikipedia.org/wiki/Sauvegarde

Il se trouve que les journaux de transaction (fichiers WAL) dans postgresql sont très exactement les pages de données qui ont été modifiées depuis un point dans le temps (le dernier CHECKPOINT en l'occurrence) plus quelques données de contrôle associées.

[SQLpro]

Entre le pg_start_backup() et le pg_stop_backup() postgres s'arrange pour maintenir les fichiers de données dans un état consistant.

Et pour se faire comment fait-il ? Magie ou verrouillage ?

Il se trouve que les journaux de transaction (fichiers WAL) dans postgresql sont très exactement les pages de données qui ont été modifiées depuis un point dans le temps (le dernier CHECKPOINT en l'occurrence) plus quelques données de contrôle associées.

Non, encore une fois rien à voir.

Si vous avez une table dont les pages ont été modifiées 100 fois, la restauration du journal de transaction replacera 100 fois la page.

Dans une sauvegarde différentielle on ne prend qu'UNE SEULE fois chaque page de données.

ça fait une TRES GROSSE DIFFERENCE en terme de durée de la sauvegarde et plus encore en terme de restauration...

A +

[estofilo]

- le forçage des paramètres niveau session pour combler l'absence de hints est une usine à gaz. D'autant que dans une même session, d'une requête à une autre, les paramètres doivent être changés en cours de route pour s'adapter à chaque requête.
Cela revient à dire au développeur qu'avant chaque requête SQL il doit potentiellement modifier 10 paramètres Postgresql à chaque fois (enable_mergejoin, enable_nestloop, enable_seqscan, ...). Bref bon courage ... !

Certes mais dans la pratique ce n'est que dans les cas pathologiques qu'on va en arriver à de telles extrémités. Les SGBDs qui ont les hints ne les présentent pas non plus comme étant la panacée, en tout cas ce n'est pas le souvenir que j'en ai avec Oracle.
En ce qui concerne Oracle d'ailleurs il est intéressant de voir qu'ils ont ajouté par-dessus les "stored outlines" (version 9 je crois) et puis encore après le système de "plan management" de la version 11.
Pour une explication très sommaire voir ce white paper:
http://www.oracle.com/technetwork/da...gr2-133099.pdf

Si ça donne l'état de l'art sur le sujet, on n'est toujours pas sortis de l'usine à gaz de toute manière...

[estofilo]

Et pour se faire comment fait-il ? Magie ou verrouillage ?

Pendant le backup à chaud, je pense qu'en écriture il ne fait plus que des ajouts dans les fichiers WAL. Ce n'est qu'une supposition ceci dit car je ne me souviens pas avoir lu une explication de comment ça fonctionnait.

[frost242]

Et pour se faire comment fait-il ? Magie ou verrouillage ?

Pas de verrouillage. PostgreSQL continue son boulot sans sourciller et sans bloquer les transactions. D'ailleurs, pour preuve, les messages de cpio indiquant que les fichiers copiés changent au cours de la sauvegarde, si elle est faite avec cpio.
Je ne connais pas l'implémentation technique dans le détail, mais je me l'explique en analysant le comportement de PG. Lorsqu'on appelle pg_start_backup() fait un CHECKPOINT et l'appel à pg_stop_backup() déclenche à nouveau un CHECKPOINT et archive l'ensemble des journaux de transactions qui ont été utilisés entre le start et le stop.

Enfin sachant qu'un backup consistant est constitué des fichiers de la base ET des WAL archivés (archive logs pour faire une analogie Oracle), on peut simplement se dire qu'ils ont durci le processus de recover: il sait s'il faut rejouer les modifications ou non.

J'espère que j'ai été clair.

[frost242]

Pendant le backup à chaud, je pense qu'en écriture il ne fait plus que des ajouts dans les fichiers WAL. Ce n'est qu'une supposition ceci dit car je ne me souviens pas avoir lu une explication de comment ça fonctionnait.

Non, il écrit aussi dans les fichiers. Cf ce que j'ai écrit
Mais pareil, je n'ai pas été lire le code pour savoir comment ça fonctionne.

[frost242]

Non, il écrit aussi dans les fichiers. Cf ce que j'ai écrit
Mais pareil, je n'ai pas été lire le code pour savoir comment ça fonctionne.

edit, ajout de:

La procédure pour ça est:

SQL> select pg_start_backup(...);
...
sauvegarde au niveau système de fichiers par un outil externe (rsync, tar, cp,...)
...
SQL> select pg_stop_backup();

Cette procédure est suivie d'une sauvegarde des WAL archivés qui ont été écrits pendant la sauvegarde. Sinon votre backup ne vaudra pas grand chose.

[Arnaud B.]

Un petit message pour dire que cet article et le présent débat qui s'ensuit sont très intéressants....

J'ai vu les messages d'insulte sur le forum posgresql.fr et j'avoue que j'ai été très déçu de la pauvreté des arguments des détracteurs de l'article (pour ainsi dire, il n'y avait aucun argument). J'attendais mieux de la part d'experts PG...

Cdlt, Arnaud.

[Arnaud B.]

Je reviens sur la reconstruction d'index à chaud (sans verrouiller la table) : c'est étonnant qu'il n'y ait pas une commande qui fasse cette opération automatiquement.

Il me semble que la plupart des SGBDR le proposent non ?

P'tite question de non-expert SGBD : pourquoi ne pas mettre le CREATE INDEX dans la transaction tant qu'à faire ?

Code :

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

1
2
3
4
5
6
 
 =# CREATE UNIQUE INDEX CONCURRENTLY idx_pk2 ON test_pk (a);
 =# BEGIN ;
 =# ALTER TABLE test_pk DROP CONSTRAINT idx_pk;
 =# ALTER TABLE test_pk ADD primary key using index idx_pk2;
 =# COMMIT ;

.