Vous n'êtes pas identifié(e).

Pages : 1 2 3 4 5 … 9

#51 Re : Sécurité » Utilisation de PGBOUNCER avec saisie d'un password » 03/06/2014 11:10:19

arthurr

bonjour,

dans votre fichier de conf, vous avez :

auth_type = trust

il faut passer en 

auth_type = md5

#52 Re : Général » DROP COLUMN : erreur 42703 » 28/05/2014 13:56:36

arthurr
mortimer.pw a écrit :

Bonjour Thomas,
Je me permets d'intervenir car en lisant votre post, je vois que le champ défini dans la table est "datemaj" alors que dans votre requête c'est "datmaj" (manque le e).

Intervention pertinente ! smile

#53 Re : Général » DROP COLUMN : erreur 42703 » 28/05/2014 11:17:52

arthurr

Bonjour,

Vous pouvez faire un "\d aep.c_3_3_50" dans la ligne de commande psql et nous poster le résultat ?
je suspecte un problème de casse (majuscules) dans le nom de la colonne

#54 Re : Installation » FATAL: XX000: too many private dirs demanded » 16/05/2014 16:21:38

arthurr

bonjour,

Une recherche rapide, me donne ceci :
http://www.postgresql.org/message-id/AA … .gmail.com
même problème que vous sur une gentoo

#55 Re : PL/pgSQL » Valeur par défaut » 16/05/2014 11:59:52

arthurr

Bonjour,
Dans la doc :
La clause DEFAULT, apparaissant dans la définition d'une colonne, permet de lui affecter une valeur par défaut. La valeur est une expression libre de variable (les sous-requêtes et références croisées aux autres colonnes de la table courante ne sont pas autorisées). Le type de données de l'expression par défaut doit correspondre au type de données de la colonne.

Pour moi, vous devez donc passer par un trigger

#56 Re : Général » [résolu] Requête sur un champs HSTORE ( mot clé "IN" ) » 16/05/2014 11:57:49

arthurr

Bonjour,

je souhaiterai donc pouvoir caster en string

postgres=# select 42::text;
 text 
------
 42
(1 row)

Par contre, aucune idée de savoir si le IN va fonctionner avec le Hstore

#57 Re : PL/pgSQL » Auto-jointure et Horodatage » 14/05/2014 10:38:14

arthurr

avec un case :

SELECT
...
CASE WHEN b = 0 THEN
 0
ELSE
 a/b
END as calcul,
...

#58 Re : PL/pgSQL » Auto-jointure et Horodatage » 13/05/2014 14:53:49

arthurr

la même en "propre" : 

Select a.now, (lead(a.now,1) over(order by a.now))-a.now as temps, a.action from ma_table a order by a.now;

Avec des données :

test=# select * from ma_table ;
            now             | action 
----------------------------+--------
 2014-05-13 14:41:19.111753 | 01
 2014-05-13 13:41:34.645092 | 02
 2014-05-13 15:41:39.804745 | 03
 2014-05-13 17:48:44.120593 | 04
(4 rows)

test=# Select a.now, (lead(a.now,1) over(order by a.now))-a.now as temps, a.action from ma_table a order by a.now;
            now             |      temps      | action 
----------------------------+-----------------+--------
 2014-05-13 13:41:34.645092 | 00:59:44.466661 | 02
 2014-05-13 14:41:19.111753 | 01:00:20.692992 | 01
 2014-05-13 15:41:39.804745 | 02:07:04.315848 | 03
 2014-05-13 17:48:44.120593 |                 | 04
(4 rows)

#59 Re : PL/pgSQL » Auto-jointure et Horodatage » 13/05/2014 14:36:46

arthurr

bonjour,

Pas très joli ma ça doit fonctionner :

Select a.now,(select b.now from ma_table b where b.now>a.now order by b.now limit 1) - a.now as temps, a.action from ma_table a order by a.now;

#60 Re : Optimisation » mauvais choix de l'optimiseur » 07/05/2014 17:08:19

arthurr

les données temporaires (qui ne tiennent pas dans le work_mem) sont écrite sur disque puis lues pour un tri par exemple

#61 Re : Optimisation » mauvais choix de l'optimiseur » 07/05/2014 16:25:15

arthurr

pour moi, le HashAggregate va utiliser du CPU et des IO sur les disques.
Faire un tri avec un CPU 1Ghz ne va pas donner les mêmes résultats qu'avec un cpu à 3.2Ghz (vous devez observer un CPU à 100% pendant le traitement de la requête).
PostgreSQL ne sait pas utiliser plusieurs CPU pour le moment, donc plus la vitesse d'un core va être rapide plus ça va aller vite.
Pour le disque, pas de mystère : si il doit écrire pour lire sur un fichier de N Go, il faut des disques rapides (SSD, RAID10 en 15k, ...).

#62 Re : Optimisation » mauvais choix de l'optimiseur » 30/04/2014 18:01:31

arthurr

Peut être une solution à creuser : une requête CTE.
Elle va prendre 9 sec (contre 6 sec pour votre requête mais avec un work_mem = 1GB) sur mon simple PC mais ne nécessite "que" 64MB de work_mem pour fonctionner.
Avec un work_mem de 32MB elle monte à 12sec

test=# set work_mem to '64MB';
SET
Time: 0,166 ms
test=# explain(analyse, verbose) WITH toto as (select distinct nivgeo_zone,codgeo_zone,nivgeo_englobe,codgeo_englobe from t1)
SELECT
sum(valeur),
inatc,
sexe,
age4,
iranr,
nivgeo_englobe,
codgeo_englobe
from
t2 data join toto on (data.nivgeo = toto.nivgeo_zone AND data.codgeo = toto.codgeo_zone)
group by 2,3,4,5,6,7;
                                                                            QUERY PLAN                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=40376.15..41106.14 rows=72999 width=64) (actual time=7817.584..9237.119 rows=4104270 loops=1)
   Output: sum(data.valeur), data.inatc, data.sexe, data.age4, data.iranr, toto.nivgeo_englobe, toto.codgeo_englobe
   Group Key: data.inatc, data.sexe, data.age4, data.iranr, toto.nivgeo_englobe, toto.codgeo_englobe
   CTE toto
     ->  HashAggregate  (cost=10004.24..10364.73 rows=36049 width=49) (actual time=189.425..296.358 rows=330062 loops=1)
           Output: t1.nivgeo_zone, t1.codgeo_zone, t1.nivgeo_englobe, t1.codgeo_englobe
           Group Key: t1.nivgeo_zone, t1.codgeo_zone, t1.nivgeo_englobe, t1.codgeo_englobe
           ->  Seq Scan on public.t1  (cost=0.00..6703.62 rows=330062 width=49) (actual time=0.002..19.243 rows=330062 loops=1)
                 Output: t1.nivgeo_zone, t1.codgeo_zone, t1.nivgeo_englobe, t1.codgeo_englobe
   ->  Merge Join  (cost=3449.89..28733.94 rows=72999 width=64) (actual time=2414.251..5089.454 rows=4492665 loops=1)
         Output: data.inatc, data.sexe, data.age4, data.iranr, data.valeur, toto.nivgeo_englobe, toto.codgeo_englobe
         Merge Cond: ((data.nivgeo = toto.nivgeo_zone) AND (data.codgeo = toto.codgeo_zone))
         ->  Index Scan using t2_nivgeo_codgeo_idx on public.t2 data  (cost=0.42..21506.11 rows=500175 width=32) (actual time=0.016..131.288 rows=500175 loops=1)
               Output: data.nivgeo, data.codgeo, data.iranr, data.inatc, data.age4, data.sexe, data.valeur
         ->  Sort  (cost=3449.47..3539.59 rows=36049 width=76) (actual time=2414.227..2636.629 rows=4492666 loops=1)
               Output: toto.nivgeo_englobe, toto.codgeo_englobe, toto.nivgeo_zone, toto.codgeo_zone
               Sort Key: toto.nivgeo_zone, toto.codgeo_zone
               Sort Method: quicksort  Memory: 55778kB
               ->  CTE Scan on toto  (cost=0.00..720.98 rows=36049 width=76) (actual time=189.428..392.457 rows=330062 loops=1)
                     Output: toto.nivgeo_englobe, toto.codgeo_englobe, toto.nivgeo_zone, toto.codgeo_zone
 Planning time: 0.185 ms
 Total runtime: 9389.032 ms
(22 rows)

Time: 9393,596 ms

#63 Re : Optimisation » mauvais choix de l'optimiseur » 30/04/2014 17:38:03

arthurr
arthurr a écrit :

Pas grand chose à faire : il doit trier 4 486 995 lignes sur 6 colonnes (zone.nivgeo_englobe, zone.codgeo_englobe, data.inatc, data.sexe, data.age4, data.iranr) -> le group by
et vu la taille, il est obligé de passer par un fichier sur disque (360Mo), les données ne tenant pas dans le work_mem.
Donc : c'est du cpu et du disque

j'ai répondu trop vite (je n'ai lu que votre dernier post et pas depuis le début) : ma réponse ne va pas aider beaucoup .... désolé

#64 Re : Optimisation » mauvais choix de l'optimiseur » 30/04/2014 16:21:11

arthurr

Pas grand chose à faire : il doit trier 4 486 995 lignes sur 6 colonnes (zone.nivgeo_englobe, zone.codgeo_englobe, data.inatc, data.sexe, data.age4, data.iranr) -> le group by
et vu la taille, il est obligé de passer par un fichier sur disque (360Mo), les données ne tenant pas dans le work_mem.
Donc : c'est du cpu et du disque

#65 Re : PL/pgSQL » fonction » 30/04/2014 10:40:19

arthurr

Celle là fonctionne bien :

test=# CREATE OR REPLACE FUNCTION unite_s (x decimal ) returns decimal AS $corps$
Begin
 return (  x /1000)::decimal(7,3) ;
end;
$corps$
LANGUAGE PLPGSQL;
CREATE FUNCTION
test=# select * from unite_s(465551);
 unite_s 
---------
 465.551
(1 row)

#66 Re : PL/pgSQL » fonction » 29/04/2014 13:47:22

arthurr
test# select (465551::decimal/1000)::decimal(7,3);
 numeric 
---------
 465.551
(1 row)

#67 Re : Migration » problème de droit sur pg_class pour runMTK » 28/04/2014 15:00:10

arthurr

Can't locate DBI.pm

Il a besoin de DBI (ainsi que du DBD::Oracle je suppose) pour se connecter à la base de données : se sont les lib de connexion standard en perl
http://search.cpan.org/~timb/DBI-1.631/DBI.pm
http://search.cpan.org/~pythian/DBD-Ora … /Oracle.pm

#68 Re : Migration » problème de droit sur pg_class pour runMTK » 24/04/2014 11:01:50

arthurr

Pour la migration d'Oracle vers Pg (données, schémas, ...) = ora2pg
le lien : http://ora2pg.darold.net/

#69 Re : Optimisation » Serveur Rsyslog » 14/04/2014 15:42:24

arthurr

Il n'utilise pas l'index que vous venez de créer, mais celui qui est sur la primary key (id).

Pouvez vous faire un "analyze systemevents" pour refaire la requête avec le "explain" ?

Pour le vacuum full : il va bloquer votre base de données le temps de réécrire le table, au mieux vous allez gagner de la place sur votre disque
Cela reste une opération de maintenance et n'est pas utilisé sauf si vous avez supprimé / updaté beaucoup de lignes sans faire des vacuum (sans full) réguliers.

#70 Re : Optimisation » Serveur Rsyslog » 14/04/2014 14:47:52

arthurr

si NomEquipement (Pg ne va pas tenir compte de la casse) existe, il faut supprimer l'index avant.
Si vous faites des like sans "%", autant conserver l'index actuel et utiliser une clause where avec "="
Pouvez vous poster un explain : 

EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 10;

#71 Re : Optimisation » Serveur Rsyslog » 14/04/2014 13:58:24

arthurr

il faut créer votre index avec varchar_pattern_ops (http://docs.postgresql.fr/9.2/indexes-opclass.html):

CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

Mais ça ne va fonctionner qu'avec un like sur la partie gauche => like 'xxx%'

#72 Re : Général » Bug PostGreSQL : FULL OUTER JOIN » 09/04/2014 12:21:23

arthurr

Que d'insultes ...

#73 Re : Général » arrondi superieur » 20/03/2014 17:59:54

arthurr

j'ai du mal à suivre ...
premier exemple que tu donnes :

round(123.121958,2) = 123.13

puis :

SELECT arrondir_sup(1.00000009,2) ;

Ce dernier exemple demande 2 chiffre après la virgule arrondi au supérieur, donc 1.01
Pour moi, si tu veux 1.10, tu fais :

postgres=# SELECT special_round(1.00000009,1);
 special_round 
---------------
           1.1

#74 Re : Général » arrondi superieur » 19/03/2014 17:23:14

arthurr

Testé chez moi :

CREATE OR REPLACE function special_round(p_to_round decimal,p_nbre_decimal integer) RETURNS decimal AS $$
DECLARE
	p_return decimal;
BEGIN
	IF(round(p_to_round,p_nbre_decimal)<p_to_round) THEN
		p_to_round := p_to_round + 9 /10^(p_nbre_decimal+1);
	END IF;
	p_return := round(p_to_round,p_nbre_decimal);
	RETURN p_return;
END;
$$ LANGUAGE plpgsql;

Tests :

test=# select * from special_round(123.121958,2);
 special_round 
---------------
        123.13
(1 row)
test=# select * from special_round(123.120,3);
 special_round 
---------------
       123.120
(1 row)

#75 Re : Optimisation » Optimisation Basse de Données » 18/03/2014 18:27:30

arthurr

Vous pouvez :
1- passer "default_statistics_target = 1000" dans le fichier de conf ?
2- faire un reload (pas un restart) du service Postgresql ?
3- faire un vacuum analyse de la base de données ?
4- nous poster un explain de la requête ?

Pages : 1 2 3 4 5 … 9

Pied de page des forums

Propulsé par FluxBB