Salut
Je fais un import toutes les nuits des données provenants d'un gros système.
j'ai remarqué que certaine requetes toutes simple prennent un temps
colossale.
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je
suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres
de ne pas mettre a jour les indexes puis de les remettre a jour unefois
l'import terminé.
Salut Je fais un import toutes les nuits des données provenants d'un gros système. j'ai remarqué que certaine requetes toutes simple prennent un temps colossale.
Normal
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans mes souvenirs la docs conseillant le drop/recreate mais c'etait y'a longtemps.
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp plus efficace
Etienne SOBOLE a écrit
Salut
Je fais un import toutes les nuits des données provenants d'un gros système.
j'ai remarqué que certaine requetes toutes simple prennent un temps
colossale.
Normal
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je
suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres
de ne pas mettre a jour les indexes puis de les remettre a jour unefois
l'import terminé.
Dans mes souvenirs la docs conseillant le drop/recreate mais c'etait
y'a longtemps.
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si
tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp
plus efficace
Salut Je fais un import toutes les nuits des données provenants d'un gros système. j'ai remarqué que certaine requetes toutes simple prennent un temps colossale.
Normal
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans mes souvenirs la docs conseillant le drop/recreate mais c'etait y'a longtemps.
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp plus efficace
Patrick Mevzek
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup. j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans une transaction : 1) drop index 2) faire l'importation 3) create index
-- 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>
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je
suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres
de ne pas mettre a jour les indexes puis de les remettre a jour unefois
l'import terminé.
Dans une transaction :
1) drop index
2) faire l'importation
3) create index
--
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>
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup. j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans une transaction : 1) drop index 2) faire l'importation 3) create index
-- 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>
ALain Montfranc
Patrick Mevzek a écrit
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup. j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans une transaction : 1) drop index 2) faire l'importation 3) create index
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Patrick Mevzek a écrit
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je
suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres
de ne pas mettre a jour les indexes puis de les remettre a jour unefois
l'import terminé.
Dans une transaction :
1) drop index
2) faire l'importation
3) create index
Tu crois qu'il fera une differentielle pour recreer l'index au moment
du commit ?
Le Mon, 05 Feb 2007 14:27:01 +0100, Etienne SOBOLE a écrit :
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je suis obligé de les recréer apres coup. j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres de ne pas mettre a jour les indexes puis de les remettre a jour unefois l'import terminé.
Dans une transaction : 1) drop index 2) faire l'importation 3) create index
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Etienne SOBOLE
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp plus efficace
hum.
le copy ne m'arrange pas car si je ne m'abuse ca remplace toute la table. hors mon insert (qui porte mal son nom) ne fait pas que des insertion, mais parfois des update voir meme rien.
bref c'est pas simple.
je vais supprimer les index puis les recréer mais c'est pas top car il va falloir que je pense a modifier mon script chaque fois que je modifie les indexes, ce qui n'est pas tres propre.
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si
tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp
plus efficace
hum.
le copy ne m'arrange pas car si je ne m'abuse ca remplace toute la table.
hors mon insert (qui porte mal son nom) ne fait pas que des insertion, mais
parfois des update voir meme rien.
bref c'est pas simple.
je vais supprimer les index puis les recréer mais c'est pas top car il va
falloir que je pense a modifier mon script chaque fois que je modifie les
indexes, ce qui n'est pas tres propre.
Tu importes les données par 'copy from' ou avec des 'insert into' ? Si tu fais des 'insert' essaye le 'copy' qui, de mémoire aussi, était bcp plus efficace
hum.
le copy ne m'arrange pas car si je ne m'abuse ca remplace toute la table. hors mon insert (qui porte mal son nom) ne fait pas que des insertion, mais parfois des update voir meme rien.
bref c'est pas simple.
je vais supprimer les index puis les recréer mais c'est pas top car il va falloir que je pense a modifier mon script chaque fois que je modifie les indexes, ce qui n'est pas tres propre.
Patrick Mevzek
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Il créera l'index de nouveau au moment du create index, oui.
-- 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>
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment
du commit ?
Il créera l'index de nouveau au moment du create index, oui.
--
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>
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Il créera l'index de nouveau au moment du create index, oui.
-- 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>
Etienne SOBOLE
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.
alors autre question. comment faire pour connaitre la liste de tous les index d'une base ou d'un table? de cette façon je pourrais les supprimer et les remettre de façon transparente.
merci
"Patrick Mevzek" a écrit dans le message de news:
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Il créera l'index de nouveau au moment du create index, oui.
-- 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>
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.
alors autre question.
comment faire pour connaitre la liste de tous les index d'une base ou d'un
table?
de cette façon je pourrais les supprimer et les remettre de façon
transparente.
merci
"Patrick Mevzek" <pm-N200701@nospam.dotandco.com> a écrit dans le message de
news: pan.2007.02.05.15.27.12.839942@nospam.dotandco.com...
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment
du commit ?
Il créera l'index de nouveau au moment du create index, oui.
--
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>
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.
alors autre question. comment faire pour connaitre la liste de tous les index d'une base ou d'un table? de cette façon je pourrais les supprimer et les remettre de façon transparente.
merci
"Patrick Mevzek" a écrit dans le message de news:
Le Mon, 05 Feb 2007 14:53:47 +0100, ALain Montfranc a écrit :
Tu crois qu'il fera une differentielle pour recreer l'index au moment du commit ?
Il créera l'index de nouveau au moment du create index, oui.
-- 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
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
alors autre question. comment faire pour connaitre la liste de tous les index d'une base ou d'un table?
di dans psql
sinon taper dans le INFORMATION_SCHEMA
-- 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>
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ?
Les effets de la transaction ne sont pas visibles par le reste du
système, qui voit donc toujours des index.
alors autre question.
comment faire pour connaitre la liste de tous les index d'une base ou d'un
table?
di dans psql
sinon taper dans le INFORMATION_SCHEMA
--
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>
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
alors autre question. comment faire pour connaitre la liste de tous les index d'une base ou d'un table?
di dans psql
sinon taper dans le INFORMATION_SCHEMA
-- 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>
see
Patrick Mevzek wrote:
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
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. -- Bruno http://errance.lirano.net (photographies)
Patrick Mevzek <pm-N200701@nospam.dotandco.com> wrote:
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ?
Les effets de la transaction ne sont pas visibles par le reste du
système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
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.
--
Bruno
http://errance.lirano.net (photographies)
Le Mon, 05 Feb 2007 16:57:53 +0100, 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
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. -- Bruno http://errance.lirano.net (photographies)
Patrick Mevzek
Le Mon, 05 Feb 2007 21:04:08 +0100, Bruno Jargot 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
Non.
=> create index i on toto(id); CREATE INDEX => begin transaction; BEGIN =*> drop index i; DROP INDEX
J'ouvre une autre fenêtre : => di Liste des relations Schéma | Nom | Type | Propriétaire | Table --------+-----------+-------+--------------+------- public | i | index | patrick | toto
Dans le mode d'isolation par défaut, c'est à dire READ COMMITED bien entendu.
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) : =*> drop table toto; DROP TABLE =*>
Dans l'autre fenêtre : => d toto Table «public.toto» Colonne | Type | Modificateurs ---------+---------+--------------- id | integer | Index : «i» btree (id)
-- 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>
Le Mon, 05 Feb 2007 21:04:08 +0100, Bruno Jargot 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 !!!
Pourquoi n'est-ce pas terrible ?
Les effets de la transaction ne sont pas visibles par le reste du
système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
Non.
patrick@test=> create index i on toto(id);
CREATE INDEX
patrick@test=> begin transaction;
BEGIN
patrick@test=*> drop index i;
DROP INDEX
J'ouvre une autre fenêtre :
patrick@test=> di
Liste des relations
Schéma | Nom | Type | Propriétaire | Table
--------+-----------+-------+--------------+-------
public | i | index | patrick | toto
Dans le mode d'isolation par défaut, c'est à dire READ COMMITED bien
entendu.
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)
--
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>
Le Mon, 05 Feb 2007 21:04:08 +0100, Bruno Jargot 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 !!!
Pourquoi n'est-ce pas terrible ? Les effets de la transaction ne sont pas visibles par le reste du système, qui voit donc toujours des index.
La destruction, création d'un index concerne *toutes* les transactions !
Non.
=> create index i on toto(id); CREATE INDEX => begin transaction; BEGIN =*> drop index i; DROP INDEX
J'ouvre une autre fenêtre : => di Liste des relations Schéma | Nom | Type | Propriétaire | Table --------+-----------+-------+--------------+------- public | i | index | patrick | toto
Dans le mode d'isolation par défaut, c'est à dire READ COMMITED bien entendu.
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) : =*> drop table toto; DROP TABLE =*>
Dans l'autre fenêtre : => d toto Table «public.toto» Colonne | Type | Modificateurs ---------+---------+--------------- id | integer | Index : «i» btree (id)
-- 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>
see
Patrick Mevzek 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) : =*> drop table toto; DROP TABLE =*>
Dans l'autre fenêtre : => 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é. -- Bruno http://errance.lirano.net (photographies)
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é.
--
Bruno
http://errance.lirano.net (photographies)
> 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) : =*> drop table toto; DROP TABLE =*>
Dans l'autre fenêtre : => 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é. -- Bruno http://errance.lirano.net (photographies)
