stopper les index sous postgreSQL

Etienne SOBOLE a écrit :

bon pour la petite histoire ca divise par 3 le temps d'import.

n'empeche que c'est pas terrble de faire ca !!!
le mieux serait de pouvoir invalider les index.

La technique proposée par Patrick n'a absolument rien de choquant, tout
du contraire !

Le fait d'effectuer ces opérations dans une transaction vous permet non
seulement d'être certain que TOUTES vos opérations sont bien effectuées
(entre autres la suppression / création de l'index !), mais aussi que
vous avez bien pu injecter TOUTES les données que vous deviez injecter.

Mes deux centimes :-)

--
Bruno Baguette - bouchon@alussinan.org

Bruno Jargot a écrit :

Patrick Mevzek <pm-N200701@nospam.dotandco.com> wrote:

Seules les commandes DML (Data Manipulation Langage) sont visibles
uniquement à l'intérieur de la transaction tant qu'elles n'ont pas été
validées. Ces commandes sont select, update, insert et delete.

Non.
On peut de la même façon supprimer une table, ca ne sera pas visible
avant le commit.

La preuve je continue dans la première fenêtre (transaction toujours pas
terminée) :
patrick@test=*> drop table toto;
DROP TABLE
patrick@test=*>

Dans l'autre fenêtre :
patrick@test=> d toto
Table «public.toto»
Colonne | Type | Modificateurs
---------+---------+---------------
id | integer |
Index :
«i» btree (id)

OK, il semblerait que j'ai dit une connerie ;-)

Visiblement, PostgreSQL s'est écarté d'Oracle sur ce point.
Par contre, pourrais-tu faire le test de lire le contenu de la table par
un select dans une autre transaction que celle où elle est supprimé ?

Peux t'on faire un rollback sur un drop table ?

Enfin, je serai curieux de comprendre comment ont fait les développeurs
de PostgreSQL pour permettre, dans une même transaction, de supprimer un
index, insérer des lignes dans la table, recréer ensuite l'index et tout
cela de manière transparente pour les autres transactions ! Les
implications me paraissent tout de même lourdes.

J'en suis épaté.

ils ont pas fait justement et cette méthode est une erreur d'usage qui
marche avec des petites tables mais si il prenait une table plus grosse
et si il y avait plus de transaction il y aurait une belle incohérence
des données ou un joli plantage

Bruno Jargot a écrit :

Patrick Mevzek <pm-N200701@nospam.dotandco.com> wrote:

Seules les commandes DML (Data Manipulation Langage) sont visibles
uniquement à l'intérieur de la transaction tant qu'elles n'ont pas été
validées. Ces commandes sont select, update, insert et delete.

Non.
On peut de la même façon supprimer une table, ca ne sera pas visible
avant le commit.

La preuve je continue dans la première fenêtre (transaction toujours pas
terminée) :
patrick@test=*> drop table toto;
DROP TABLE
patrick@test=*>

Dans l'autre fenêtre :
patrick@test=> d toto
Table «public.toto»
Colonne | Type | Modificateurs
---------+---------+---------------
id | integer |
Index :
«i» btree (id)

OK, il semblerait que j'ai dit une connerie ;-)

Visiblement, PostgreSQL s'est écarté d'Oracle sur ce point.
Par contre, pourrais-tu faire le test de lire le contenu de la table par
un select dans une autre transaction que celle où elle est supprimé ?

Peux t'on faire un rollback sur un drop table ?

Enfin, je serai curieux de comprendre comment ont fait les développeurs
de PostgreSQL pour permettre, dans une même transaction, de supprimer un
index, insérer des lignes dans la table, recréer ensuite l'index et tout
cela de manière transparente pour les autres transactions ! Les
implications me paraissent tout de même lourdes.

J'en suis épaté.

C'est ce que fait SQL Server depuis des lustres et dans SQL Server,
contrairement à Oracle, les transactions portent aussi sur le DML.
C'est d'ailleurs la norme SQL qui nous intime que TOUS les ordres SQL
puissent être transactionnés, y compris les ordres du DCL (GRANT / REVOKE).
Comme sur beaucoup de points Oracle ne respecte pas la norme.

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Fred Brouard - SQLpro a écrit :

Bruno Jargot a écrit :

Patrick Mevzek <pm-N200701@nospam.dotandco.com> wrote:

Seules les commandes DML (Data Manipulation Langage) sont visibles
uniquement à l'intérieur de la transaction tant qu'elles n'ont pas été
validées. Ces commandes sont select, update, insert et delete.

Non.
On peut de la même façon supprimer une table, ca ne sera pas visible
avant le commit.

La preuve je continue dans la première fenêtre (transaction toujours pas
terminée) :
patrick@test=*> drop table toto;
DROP TABLE
patrick@test=*>

Dans l'autre fenêtre :
patrick@test=> d toto
Table «public.toto»
Colonne | Type | Modificateurs
---------+---------+---------------
id | integer |
Index :
«i» btree (id)

OK, il semblerait que j'ai dit une connerie ;-)

Visiblement, PostgreSQL s'est écarté d'Oracle sur ce point.
Par contre, pourrais-tu faire le test de lire le contenu de la table par
un select dans une autre transaction que celle où elle est supprimé ?

Peux t'on faire un rollback sur un drop table ?

Enfin, je serai curieux de comprendre comment ont fait les développeurs
de PostgreSQL pour permettre, dans une même transaction, de supprimer un
index, insérer des lignes dans la table, recréer ensuite l'index et tout
cela de manière transparente pour les autres transactions ! Les
implications me paraissent tout de même lourdes.

J'en suis épaté.

C'est ce que fait SQL Server depuis des lustres et dans SQL Server,
contrairement à Oracle, les transactions portent aussi sur le DML.
C'est d'ailleurs la norme SQL qui nous intime que TOUS les ordres SQL
puissent être transactionnés, y compris les ordres du DCL (GRANT / REVOKE).
Comme sur beaucoup de points Oracle ne respecte pas la norme.

A +

c'est donc pour cela que Oracle est le top sous SQL et SQLserver une
infame M.RD.

Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net

PS j'ai parler de toi (Fred Brouard) a des personnes faisant autorité en
SGBDR sous SQL et qui sont responsables de publication sur les SGBDR
resultat tu les EMM..avec tes interventions (style MSaccess est une
merde ..... ) par contre ils m'ont demandé des articles sur les SGBDR MV :-)

Le Tue, 06 Feb 2007 06:50:11 +0100, Bruno Jargot a écrit :

Par contre, pourrais-tu faire le test de lire le contenu de la table par
un select dans une autre transaction que celle où elle est supprimé ?

Ca ne pose pas de problème, on y a accès, comme si rien ne s'y était
passé.

patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

patrick@test=> begin transaction;
BEGIN
patrick@test=*> drop table toto;
DROP TABLE
patrick@test=*> select * from toto;
ERROR: relation "toto" does not exist
patrick@test=!>

(autre connexion)
patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

Peux t'on faire un rollback sur un drop table ?

Oui.
Je reviens dans la première et termine la transaction :
patrick@test=!> rollback;
ROLLBACK
patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

Enfin, je serai curieux de comprendre comment ont fait les développeurs
de PostgreSQL pour permettre, dans une même transaction, de supprimer un
index, insérer des lignes dans la table, recréer ensuite l'index et tout
cela de manière transparente pour les autres transactions ! Les
implications me paraissent tout de même lourdes.

Les index utilisent la même technique que les tables : MVCC
En résumé (je suis loin d'être un expert de la chose), chaque
information dans la base a en plus un numéro de transaction qui indique
à partir de quel numéro de transaction/ou jusqu'à quel numéro de
transaction la donnée en question est visible.

Donc un index/une entrée dans un index peut être visible par une
transaction mais pas par une autre.

J'en suis épaté.

PostgreSQL est épatant :-)

Cela ne pose bien entendu pas plus de problèmes si la table est grosse ou
si il y a plusieurs transactions en parallèle, seuls les gens qui n'y
connaissent rien oseraient le prétendre : j'encourage ces derniers à
s'inscrire aux cours de la mairie de Paris, c'est pas cher du tout et
ils y apprendraient/comprendraient cela.

Ce n'est pas une propriété émergent «par hasard» du système ni un
hack : c'est prévu ainsi et ca fonctionne ainsi. Je pense que c'est le
cas depuis que les transactions existent dans PostgreSQL, ce qui fait un
bail. En tout cas c'est loin d'être une nouveauté.

La seule chose qu'on ne peut pas «ROLLBACKer» c'est les numéros de
séquence. Une fois qu'on a fait un nextval() dans une transaction même
si elle se termine en ROLLBACK, le numéro en question de la séquence est
définitivement perdu. C'est semble-t-il le seul moyen d'assurer à 100%
de ne jamais avoir deux fois le même numéro pris par deux clients.
Et ce n'est de toute façon pas grave, une séquence n'a en général pas
de sémantique liée, c'est juste pour construire une clef primaire.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek a écrit :

Le Tue, 06 Feb 2007 06:50:11 +0100, Bruno Jargot a écrit :

Par contre, pourrais-tu faire le test de lire le contenu de la table par
un select dans une autre transaction que celle où elle est supprimé ?

Ca ne pose pas de problème, on y a accès, comme si rien ne s'y était
passé.

patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

patrick@test=> begin transaction;
BEGIN
patrick@test=*> drop table toto;
DROP TABLE
patrick@test=*> select * from toto;
ERROR: relation "toto" does not exist
patrick@test=!>

(autre connexion)
patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

Peux t'on faire un rollback sur un drop table ?

Oui.
Je reviens dans la première et termine la transaction :
patrick@test=!> rollback;
ROLLBACK
patrick@test=> select * from toto;
id
----
42
5
6
7
8
(5 lignes)

Enfin, je serai curieux de comprendre comment ont fait les développeurs
de PostgreSQL pour permettre, dans une même transaction, de supprimer un
index, insérer des lignes dans la table, recréer ensuite l'index et tout
cela de manière transparente pour les autres transactions ! Les
implications me paraissent tout de même lourdes.

Les index utilisent la même technique que les tables : MVCC
En résumé (je suis loin d'être un expert de la chose), chaque
information dans la base a en plus un numéro de transaction qui indique
à partir de quel numéro de transaction/ou jusqu'à quel numéro de
transaction la donnée en question est visible.

Donc un index/une entrée dans un index peut être visible par une
transaction mais pas par une autre.

J'en suis épaté.

PostgreSQL est épatant :-)

Cela ne pose bien entendu pas plus de problèmes si la table est grosse ou
si il y a plusieurs transactions en parallèle, seuls les gens qui n'y
connaissent rien oseraient le prétendre : j'encourage ces derniers à
s'inscrire aux cours de la mairie de Paris, c'est pas cher du tout et
ils y apprendraient/comprendraient cela.

Ce n'est pas une propriété émergent «par hasard» du système ni un
hack : c'est prévu ainsi et ca fonctionne ainsi. Je pense que c'est le
cas depuis que les transactions existent dans PostgreSQL, ce qui fait un
bail. En tout cas c'est loin d'être une nouveauté.

La seule chose qu'on ne peut pas «ROLLBACKer» c'est les numéros de
séquence. Une fois qu'on a fait un nextval() dans une transaction même
si elle se termine en ROLLBACK, le numéro en question de la séquence est
définitivement perdu. C'est semble-t-il le seul moyen d'assurer à 100%
de ne jamais avoir deux fois le même numéro pris par deux clients.
Et ce n'est de toute façon pas grave, une séquence n'a en général pas
de sémantique liée, c'est juste pour construire une clef primaire.

ok comme cela je suis d'accord si tu vires l'index dans une transaction
certain type d'autres transactions peuvent quand meme utilisé l'index en
lecture mais pas tout les types par exemple un nextval() interdit ce
type de fonctionnement

helios a écrit :

ok comme cela je suis d'accord si tu vires l'index dans une transaction
certain type d'autres transactions peuvent quand meme utilisé l'index en
lecture mais pas tout les types par exemple un nextval() interdit ce
type de fonctionnement

Que voulez-vous dire exactement ?

L'utilisation de la fonction nextval() dans une transaction ne pose
absolument aucun problème, y compris si elle est appellée simultanément
pour une même séquence par plusieurs transactions.

Il est *certain* que la fonction nextval() retournera toujours une
valeur différente.

--
Bruno Baguette - bouchon@alussinan.org

Bruno Baguette a écrit :

helios a écrit :

ok comme cela je suis d'accord si tu vires l'index dans une transaction
certain type d'autres transactions peuvent quand meme utilisé l'index
en lecture mais pas tout les types par exemple un nextval() interdit
ce type de fonctionnement

Que voulez-vous dire exactement ?

L'utilisation de la fonction nextval() dans une transaction ne pose
absolument aucun problème, y compris si elle est appellée simultanément
pour une même séquence par plusieurs transactions.

Il est *certain* que la fonction nextval() retournera toujours une
valeur différente.

mais nextval() ne fonctionnera pas si une transaction a virer l'index

helios a écrit

mais nextval() ne fonctionnera pas si une transaction a virer l'index

1/ Vous confondez index et sequence
2/ De toutes façon votre affirmation n'a aucun sens :
- soit la transaction est terminée et l'action *désirée* est
terminée
et la ressource demandée n'a plus lieu d'être appellée
- soit la transaction est encore en cours auquel cas les processus
extérieur à la transaction ont encore accès à la ressource en
cours
de destruction (potentielle)

helios a écrit :

mais nextval() ne fonctionnera pas si une transaction a virer l'index

Pardon ?

Une séquence est tout à fait indépendante, elle ne dépend ni d'un index,
ni même d'une table.

--
Bruno Baguette - bouchon@alussinan.org