Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 16/01/2013 17:23:03
- ruizsebastien
- Membre
[RESOLU] Forcer le tri dans le tablespace temp
Bonjour,
La documentation postgresql nous dit ceci :
"Les fichiers temporaires (pour des opérations comme le tri de plus de données que ce que la mémoire peut contenir) sont créés à l'intérieur de PGDATA/base/pgsql_tmp, ou dans un sous-répertoire pgsql_tmp du répertoire du tablespace si un tablespace autre que pg_default est indiqué pour eux. Le nom du fichier temporaire est de la forme pgsql_tmpPPP.NNN, où PPP est le PID du serveur propriétaire et NNN distingue les différents fichiers temporaires de ce serveur. "
Chez nous les opérations de tri (order by, groupby, etc...) sont bien faite dans le tablespace temporaire défini par "temp_tablespaces" dans pg_settings (qui est pour nous : /P0K2YY51_2/tmp/PG_9.1_201105231/pgsql_tmp).
Mais nous voyons dans nos logs (pg_log) que certaines opérations comme de gros insert produisent des fichiers temporaires dans un file system qui contient les data (/P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp).
Est-ce normal et comment pouvons nous forcer tous ces fichiers temporaires à aller dans "temp_tablespaces" ?
Un exemple :
INSERT INTO COT_COUVERTURE
SELECT trv.idedos, trv.idessc, trv.noctr FROM DOSSIER_TRV trv
Insert on cot_couverture (cost=0.00..50039.04 rows=1748352 width=24)
-> Seq Scan on dossier_trv trv (cost=0.00..50039.04 rows=1748352 width=24)
2013-01-16 11:40:45 CET [14593]: [16-1] user=mcod_b,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp14593.4", size 44960818
2013-01-16 11:40:45 CET [14593]: [17-1] user=mcod_b,db=choregie_dbSTATEMENT: SELECT P_EnrDonneesCalculCot_Personne(185,'MCOT,CC,011P,0,2')
2013-01-16 11:40:47 CET [14593]: [18-1] user=mcod_b,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp14593.5", size 154718280
On voit ici que le temporary file est générer dans le tablespace 16385 qui correspond chez nous à /P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp...
Dernière modification par ruizsebastien (04/03/2013 10:47:02)
Cordialement,
Sébastien.
Hors ligne
#2 16/01/2013 22:51:29
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Vous parlez d'un INSERT et ce qu'on voit dans le log correspond à l'appel d'une procédure stockée. Que contient cette procédure stockée ? parce que je ne vois pas du tout pourquoi PostgreSQL utiliserait un fichier temporaire pour un INSERT sans ORDER BY ou jointure.
Guillaume.
Hors ligne
#3 17/01/2013 10:08:03
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
Effectivement la requête de la fonction qui génère des fichiers temporaires serait la suivante :
INSERT INTO COT_ADHESIONCOUVERTURE(ideah, idecvt)
SELECT map1.idesq, map2.idesq
FROM ADHESION_TRV a
INNER JOIN COUVERTURES_TRV cv
ON cv.ideah = a.ideah
INNER JOIN MAPPING_TRV map1
ON map1.cle = 'ideah'
AND map1.idecar = a.ideah
INNER JOIN MAPPING_TRV map2
ON map2.cle = 'idecvt'
AND map2.idecar = cv.idecvt
WHERE a.top = 'I';
Mais ce que l'on ne comprend pas c'est pourquoi les temp sont générés dans /P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp au lieu de /P0K2YY51_2/tmp/PG_9.1_201105231/pgsql_tmp ?
Cordialement,
Sébastien.
Hors ligne
#4 23/01/2013 10:26:23
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
Quelqu'un a une idée ? parce que ce genre de comportement sur les fichiers temporaires fait exploser nos files system...
Cordialement,
Sébastien.
Hors ligne
#5 23/01/2013 10:44:41
- rjuju
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Il est possible de définir le ou les tablespace temporaires à plusieurs endroits. Quelle valeur avez-vous dans le postgresql.conf pour la variable temp_tablespaces ? Est-il surchargé sur la base de donnée, sur l'utilisateur ou dans la session ?
Si plusieurs sont définis, postgres les utilisera chacun son tour.
Julien.
https://rjuju.github.io/
Hors ligne
#6 23/01/2013 10:54:48
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
Bonjour,
Dans le postgresql.conf : temp_tablespaces = 'temp' (TABLESPACE temp LOCATION '/P0K2YY51_2/tmp';)
Au niveau de la base de données : TABLESPACE = choregie_db_data (/P0K2YY51_1/data/choregie_db/choregie_db_data)
Au niveau du user : SET default_tablespace = 'user_data'; (/P0K2YY51_1/data/choregie_db/user_data)
Au niveau de la session, je ne sais pas.
Donc à mon sens il n'y a qu'un seul tablespace temporaire définit dans nos cluster : "temp"
select * from pg_tablespace :
"pg_default";10;""
"pg_global";10;""
"temp";10;"/P0K2YY51_2/tmp"
"choregie_db_data";10;"/P0K2YY51_1/data/choregie_db/choregie_db_data"
"choregie_db_idx";10;"/P0K2YY51_2/idx/choregie_db/choregie_db_idx"
"sdbd_choregie_db_data";16388;"/P0K2YY51_1/data/choregie_db/sdbd_data"
"sdbd_choregie_db_idx";16388;"/P0K2YY51_2/idx/choregie_db/sdbd_idx"
"clog_data";17942;"/P0K2YY51_1/data/choregie_db/clog_data"
"clog_idx";17942;"/P0K2YY51_2/idx/choregie_db/clog_idx"
"clog_trv";17942;"/P0K2YY51_2/trv/choregie_db/clog_trv"
"mcod_data";28107;"/P0K2YY51_1/data/choregie_db/mcod_data"
"mcod_idx";28107;"/P0K2YY51_2/idx/choregie_db/mcod_idx"
"mcod_trv";28107;"/P0K2YY51_2/trv/choregie_db/mcod_trv"
Cordialement,
Sébastien.
Hors ligne
#7 24/02/2013 19:19:28
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Désolé pour le manque de réponse. En regardant le INSERT, la seule raison que je vois pour laquelle il générerait des fichiers temporaires est qu'il passerait par des HashAggregate. Pouvez-vous donner le plan d'exécution du INSERT ? (un EXPLAIN sans ANALYZE).
Guillaume.
Hors ligne
#8 24/02/2013 19:21:25
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Oh, autre chose, un moyen pour être certain que PostgreSQL écrit des fichiers temporaires est de tracer leur création. Pour cela, placer log_temp_files à 0.
Guillaume.
Hors ligne
#9 24/02/2013 19:34:58
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Enfin, dernière note pour aujourd'hui, j'ai essayé de monter un test. Pour moi, il montre que cela fonctionne comme prévu :
postgres=# create tablespace db1 location '/opt/postgresql-9.2/db1';
CREATE TABLESPACE
postgres=# create database db1 tablespace db1;
CREATE DATABASE
postgres=# \c db1
You are now connected to database "db1" as user "guillaume".
db1=# create table t1 (c1 integer, c2 integer);
CREATE TABLE
db1=# create table t2 (c1 integer, c2 integer);
CREATE TABLE
db1=# create table t3 (c1 integer, c2 integer);
CREATE TABLE
db1=# insert into t1 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
db1=# insert into t2 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
db1=# insert into t3 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
db1=# show temp_tablespaces ;
temp_tablespaces
------------------
temp
(1 row)
db1=# explain analyze select t1.c1, t2.c2, t3.c2 from t1 join t2 on t1.c1=t2.c1 join t3 on t2.c1=t3.c1;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Merge Join (cost=401379.46..318496520035.65 rows=21228590216442 width=12) (actual time=1948.591..3343.789 rows=1000000 loops=1)
Merge Cond: (t3.c1 = t1.c1)
-> Sort (cost=133793.15..136160.53 rows=946950 width=8) (actual time=655.040..775.805 rows=1000000 loops=1)
Sort Key: t3.c1
Sort Method: external sort Disk: 17608kB
-> Seq Scan on t3 (cost=0.00..13894.50 rows=946950 width=8) (actual time=0.066..160.192 rows=1000000 loops=1)
-> Materialize (cost=267586.31..78737189.89 rows=4483571512 width=12) (actual time=1293.542..2166.818 rows=1000000 loops=1)
-> Merge Join (cost=267586.31..67528261.11 rows=4483571512 width=12) (actual time=1293.537..2010.638 rows=1000000 loops=1)
Merge Cond: (t1.c1 = t2.c1)
-> Sort (cost=133793.15..136160.53 rows=946950 width=4) (actual time=626.027..741.727 rows=1000000 loops=1)
Sort Key: t1.c1
Sort Method: external sort Disk: 13688kB
-> Seq Scan on t1 (cost=0.00..13894.50 rows=946950 width=4) (actual time=0.081..150.144 rows=1000000 loops=1)
-> Materialize (cost=133793.15..138527.90 rows=946950 width=8) (actual time=667.501..902.148 rows=1000000 loops=1)
-> Sort (cost=133793.15..136160.53 rows=946950 width=8) (actual time=667.497..790.738 rows=1000000 loops=1)
Sort Key: t2.c1
Sort Method: external sort Disk: 17608kB
-> Seq Scan on t2 (cost=0.00..13894.50 rows=946950 width=8) (actual time=0.045..177.096 rows=1000000 loops=1)
Total runtime: 3387.223 ms
(19 rows)
db1=# set enable_sort to off;
SET
db1=# explain analyze select t1.c1, t2.c2, t3.c2 from t1 join t2 on t1.c1=t2.c1 join t3 on t2.c1=t3.c1;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=61664.00..136483.00 rows=1000000 width=12) (actual time=625.686..2128.473 rows=1000000 loops=1)
Hash Cond: (t1.c1 = t3.c1)
-> Hash Join (cost=30832.00..74478.00 rows=1000000 width=12) (actual time=310.527..1132.626 rows=1000000 loops=1)
Hash Cond: (t1.c1 = t2.c1)
-> Seq Scan on t1 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.017..135.661 rows=1000000 loops=1)
-> Hash (cost=14425.00..14425.00 rows=1000000 width=8) (actual time=308.291..308.291 rows=1000000 loops=1)
Buckets: 4096 Batches: 64 Memory Usage: 625kB
-> Seq Scan on t2 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.011..135.527 rows=1000000 loops=1)
-> Hash (cost=14425.00..14425.00 rows=1000000 width=8) (actual time=315.101..315.101 rows=1000000 loops=1)
Buckets: 4096 Batches: 64 Memory Usage: 625kB
-> Seq Scan on t3 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.038..137.582 rows=1000000 loops=1)
Total runtime: 2161.899 ms
(12 rows)Que ce soit pour un tri ou pour un hachage, les données temporaires vont bien dans le bon tablespace, comme le montrent les traces :
2013-02-24 18:30:32 CET [30105]: [18-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.5", size 18030592
2013-02-24 18:30:32 CET [30105]: [20-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.4", size 14016512
2013-02-24 18:30:32 CET [30105]: [22-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.3", size 18030592
2013-02-24 18:31:02 CET [30105]: [28-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.76", size 435876
2013-02-24 18:31:02 CET [30105]: [30-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.139", size 373608
2013-02-24 18:31:02 CET [30105]: [32-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.72", size 439460
2013-02-24 18:31:02 CET [30105]: [34-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.135", size 376680
2013-02-24 18:31:02 CET [30105]: [36-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.79", size 436968
2013-02-24 18:31:02 CET [30105]: [38-1] user=guillaume,db=db1 LOG: temporary file: path "pg_tblspc/25506/PG_9.2_201204301/pgsql_tmp/pgsql_tmp30105.142", size 37454425506 étant le tablespace temp pour mes fichiers temporaires (celui de la base db1 est 25507).
Bref, pour moi, cela fonctionne comme prévu.
Guillaume.
Hors ligne
#10 26/02/2013 12:18:32
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
bonjour,
Voici le plan :
"Insert on cot_adhesioncouverture (cost=6.17..8.75 rows=1 width=16)"
" -> Nested Loop (cost=6.17..8.75 rows=1 width=16)"
" -> Nested Loop (cost=6.17..8.00 rows=1 width=18)"
" -> Merge Join (cost=6.17..7.65 rows=1 width=13)"
" Merge Cond: ((cv.idecvt)::text = (map2.idecar)::text)"
" -> Sort (cost=6.17..6.41 rows=97 width=70)"
" Sort Key: cv.idecvt"
" -> Seq Scan on couvertures_trv cv (cost=0.00..2.97 rows=97 width=70)"
" -> Index Scan using mapping_trv_is2 on mapping_trv map2 (cost=0.00..15.73 rows=97 width=39)"
" Index Cond: ((cle)::text = 'idecvt'::text)"
" -> Index Scan using adhesion_trv_is2 on adhesion_trv a (cost=0.00..0.33 rows=1 width=5)"
" Index Cond: ((ideah)::text = (cv.ideah)::text)"
" Filter: ((top)::text = 'I'::text)"
" -> Index Scan using mapping_trv_is2 on mapping_trv map1 (cost=0.00..0.73 rows=1 width=39)"
" Index Cond: (((cle)::text = 'ideah'::text) AND ((idecar)::text = (cv.ideah)::text))"
Cordialement,
Sébastien.
Hors ligne
#11 26/02/2013 17:43:34
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
La seule opération qui peut générer des fichiers temporaires est le Sort. J'ai du mal à croire que pour 97 lignes d'une largeur de 70 octets, il ait besoin de passer par des fichiers temporaires. Bref, comme dit dans la dernière note, mieux vaut placer log_temp_files à 0 pour en savoir plus.
Guillaume.
Hors ligne
#12 26/02/2013 18:08:09
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
j'ai refait le plan sur un cluster avec de la volumétrie :
"Insert on cot_adhesioncouverture (cost=185750.98..209292.41 rows=225 width=16)"
" -> Merge Join (cost=185750.98..209292.41 rows=225 width=16)"
" Merge Cond: ((cv.idecvt)::text = (map2.idecar)::text)"
" -> Sort (cost=185750.82..185797.72 rows=18757 width=73)"
" Sort Key: cv.idecvt"
" -> Nested Loop (cost=21536.18..184419.53 rows=18757 width=73)"
" -> Merge Join (cost=21536.18..113374.87 rows=11430 width=60)"
" Merge Cond: ((a.ideah)::text = (map1.idecar)::text)"
" -> Index Scan using adhesion_trv_is2 on adhesion_trv a (cost=0.00..62701.34 rows=1497437 width=15)"
" Filter: ((top)::text = 'I'::text)"
" -> Index Scan using mapping_trv_is2 on mapping_trv map1 (cost=0.00..283046.50 rows=1443581 width=45)"
" Index Cond: ((cle)::text = 'ideah'::text)"
" -> Index Scan using couvertures_trv_is3 on couvertures_trv cv (cost=0.00..6.18 rows=3 width=80)"
" Index Cond: ((ideah)::text = (a.ideah)::text)"
" -> Index Scan using mapping_trv_is2 on mapping_trv map2 (cost=0.00..313257.70 rows=2273485 width=45)"
" Index Cond: ((cle)::text = 'idecvt'::text)"
et nous avions déjà mis log_temp_files à 0 ce qui nous avez permis de voir que des fichiers temporaires étaient créés ailleurs que prévu (ailleurs que dans temp_tablespaces = 'temp').
Cordialement,
Sébastien.
Hors ligne
#13 26/02/2013 20:57:48
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Je n'ai pas reproduit le problème avec une 9.2. À priori, vous avez une 9.1. Quelle version précise avez-vous ?
Guillaume.
Hors ligne
#14 27/02/2013 10:58:26
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
9.1.2
Cordialement,
Sébastien.
Hors ligne
#15 27/02/2013 22:39:20
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
J'ai installé une 9.1.2 ainsi que la dernière 9.1 (la 9.1.8). En suivant mon jeu de tests, je ne reproduis pas votre problème. J'ai aussi ajouté un tablespace par défaut pour mon utilisateur, cela ne change rien. Enfin, j'ai regardé le changelog des versions 9.1, et je n'ai rien vu relatif à votre problème.
Pouvez-vous produire un petit test, un peu comme ce que j'ai fait ci-dessus qui montrerait le problème ?
Guillaume.
Hors ligne
#16 28/02/2013 12:41:26
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
Bonjour Guillaume,
J'ai reproduis le test que vous avez fait ci-dessus :
Liste des tablespaces :
16384 -> /D1DAYY50_2/tmp
16386 -> /D1DAYY50_2/idx/choregie_db/choregie_db_idx
16385 -> /D1DAYY50_1/data/choregie_db/choregie_db_data
16390 -> /D1DAYY50_2/idx/choregie_db/sdbd_idx
16389 -> /D1DAYY50_1/data/choregie_db/sdbd_data
16774 -> /D1DAYY50_2/trv/choregie_db/cpro_trv
16773 -> /D1DAYY50_2/idx/choregie_db/cpro_idx
16772 -> /D1DAYY50_1/data/choregie_db/cpro_data
16886 -> /D1DAYY50_2/trv/choregie_db/clog_trv
16885 -> /D1DAYY50_2/idx/choregie_db/clog_idx
16884 -> /D1DAYY50_1/data/choregie_db/clog_data
19209 -> /D1DAYY50_2/idx/choregie_db/mcod_idx
19208 -> /D1DAYY50_1/data/choregie_db/mcod_data
19210 -> /D1DAYY50_2/trv/choregie_db/mcod_trv
24813 -> /D1DAYY50_2/trv/choregie_db/mcod2_trv
24812 -> /D1DAYY50_2/idx/choregie_db/mcod2_idx
24811 -> /D1DAYY50_1/data/choregie_db/mcod2_data
1er test avec un superuser :
choregie_db=# create table t1 (c1 integer, c2 integer);
CREATE TABLE
choregie_db=# create table t2 (c1 integer, c2 integer);
CREATE TABLE
choregie_db=# create table t3 (c1 integer, c2 integer);
CREATE TABLE
choregie_db=# insert into t1 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
choregie_db=# insert into t2 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
choregie_db=# insert into t3 select i, i+1 from generate_series(1, 1000000) as i;
INSERT 0 1000000
choregie_db=# show temp_tablespaces ;
temp_tablespaces
------------------
temp
(1 row)choregie_db=# explain analyze select t1.c1, t2.c2, t3.c2 from t1 join t2 on t1.c1=t2.c1 join t3 on t2.c1=t3.c1;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=96861.00..141483.00 rows=1000000 width=12) (actual time=3014.398..4411.927 rows=1000000 loops=1)
Hash Cond: (t1.c1 = t2.c1)
-> Seq Scan on t1 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.040..289.657 rows=1000000 loops=1)
-> Hash (cost=79478.00..79478.00 rows=1000000 width=16) (actual time=3014.059..3014.059 rows=1000000 loops=1)
Buckets: 32768 Batches: 8 Memory Usage: 5873kB
-> Hash Join (cost=30832.00..79478.00 rows=1000000 width=16) (actual time=625.612..2629.732 rows=1000000 loops=1)
Hash Cond: (t2.c1 = t3.c1)
-> Seq Scan on t2 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.029..312.378 rows=1000000 loops=1)
-> Hash (cost=14425.00..14425.00 rows=1000000 width=8) (actual time=625.305..625.305 rows=1000000 loops=1)
Buckets: 32768 Batches: 4 Memory Usage: 9774kB
-> Seq Scan on t3 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.046..300.418 rows=1000000 loops=1)
Total runtime: 4497.734 ms
(12 rows)choregie_db=# set enable_sort to off;
SET
choregie_db=# explain analyze select t1.c1, t2.c2, t3.c2 from t1 join t2 on t1.c1=t2.c1 join t3 on t2.c1=t3.c1;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=96861.00..141483.00 rows=1000000 width=12) (actual time=2947.402..4259.715 rows=1000000 loops=1)
Hash Cond: (t1.c1 = t2.c1)
-> Seq Scan on t1 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.026..221.649 rows=1000000 loops=1)
-> Hash (cost=79478.00..79478.00 rows=1000000 width=16) (actual time=2947.172..2947.172 rows=1000000 loops=1)
Buckets: 32768 Batches: 8 Memory Usage: 5873kB
-> Hash Join (cost=30832.00..79478.00 rows=1000000 width=16) (actual time=544.431..2563.179 rows=1000000 loops=1)
Hash Cond: (t2.c1 = t3.c1)
-> Seq Scan on t2 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.032..239.304 rows=1000000 loops=1)
-> Hash (cost=14425.00..14425.00 rows=1000000 width=8) (actual time=544.221..544.221 rows=1000000 loops=1)
Buckets: 32768 Batches: 4 Memory Usage: 9774kB
-> Seq Scan on t3 (cost=0.00..14425.00 rows=1000000 width=8) (actual time=0.012..235.212 rows=1000000 loops=1)
Total runtime: 4346.078 ms
(12 rows)
Résultat dans le log postgresql :
2013-02-28 11:12:11 CET [7493]: [6-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.1", size 6990004
2013-02-28 11:12:11 CET [7493]: [8-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.4", size 6990004
2013-02-28 11:12:11 CET [7493]: [10-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.0", size 7001568
2013-02-28 11:12:12 CET [7493]: [12-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.3", size 7001568
2013-02-28 11:12:12 CET [7493]: [14-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.2", size 7005852
2013-02-28 11:12:12 CET [7493]: [16-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.5", size 7005852
2013-02-28 11:12:13 CET [7493]: [18-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.8", size 4497336
2013-02-28 11:12:13 CET [7493]: [20-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.16", size 2998224
2013-02-28 11:12:13 CET [7493]: [22-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.10", size 4503024
2013-02-28 11:12:13 CET [7493]: [24-1] user=sdbd,db=choregie_dbLOG: temporary file: path "pg_tblspc/16384/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7493.19", size 3002016
etc...
2ème test (identique au premier) avec un user standard, résultat du log postgresql :
2013-02-28 11:21:51 CET [7721]: [10-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.0", size 14000000
2013-02-28 11:22:51 CET [7721]: [14-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.1", size 14000000
2013-02-28 11:22:59 CET [7721]: [18-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.2", size 14000000
2013-02-28 11:23:12 CET [7721]: [22-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.4", size 5991432
2013-02-28 11:23:12 CET [7721]: [24-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.7", size 6990004
2013-02-28 11:23:12 CET [7721]: [26-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.3", size 6001344
2013-02-28 11:23:13 CET [7721]: [28-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp7721.6", size 7001568
On voit bien dans le 2ème cas que les fichiers temporaires ne sont pas créés au bon endroit (dans le tablespace 16384).
Voici la définition du user qui m'a servi lors du 2ème test :
CREATE ROLE mcod LOGIN
ENCRYPTED PASSWORD 'md502a669307a4f88e39c45413e3ebf2b0e'
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;ALTER ROLE mcod
SET default_tablespace = 'mcod_data';
GRANT owner TO mcod;
et voici les paramètres "temp" du cluster :
"log_temp_files";"0"
"stats_temp_directory";"pg_stat_tmp"
"temp_buffers";"1024"
"temp_tablespaces";"temp"CREATE TABLESPACE temp
OWNER postgres
LOCATION '/D1DAYY50_2/tmp';
Cordialement,
Sébastien.
Hors ligne
#17 28/02/2013 22:56:28
- gleu
- Administrateur
Re : [RESOLU] Forcer le tri dans le tablespace temp
Ah OK, compris. Votre utilisateur n'a pas de droit sur le tablespace des fichiers temporaires. Essayez un "GRANT CREATE ON TABLESPACE temp TO mcod;", ça devrait aller mieux.
Guillaume.
Hors ligne
#18 04/03/2013 10:46:36
- ruizsebastien
- Membre
Re : [RESOLU] Forcer le tri dans le tablespace temp
Bonjour Guillaume,
C'est ça, il manquait aux simples users les droits de create dans le tablespace temp.
Merci pour votre aide.
Cordialement,
Sébastien.
Hors ligne
Pages : 1