Bonjour,

Désolé de ne pas avoir donné de nouvelles depuis. L'auteur a poussé le correctif adéquat pour gérer correctement pg_stat_statements: le patch appliqué.

Vous devriez pouvoir récupérer la dernière version et faire fonctionner pgstatspack correctement dorénavant.

Bonjour,

Dans un premier temps, il va vous falloir modifier le script sql/pgstatspack_create_snap.sql pour corriger la condition jointure mal écrite (ligne 203 du script SQL):

    join pgstatspack_names n1 on s.query=n1.name

Une fois que c'est fait, il vous faudra recréer la fonction pgstatspack_snap en exécutant le script sur la base sur laquelle vous avez rencontrez ce problème.

Je remonte le bug à l'auteur.

Cordialement,
Thomas

Ce que je vois, c'est que votre nouvel index n'est utilisé dans aucun cas (cf première ligne de l'explain qui donne un seq scan, donc une lecture séquentielle pour les deux requêtes).
La différence de temps d'exécution s'explique car pour la première requête, PostgreSQL va calculer le résultat de lower(erpunaccent(name)) pour chaque ligne lues et le comparer à 'ogvvatoies%' avec le LIKE. Dans le second cas, PostgreSQL va comparer directement la colonne name à 'oGvvÀtÖiÉ%', mais sans le moindre calcul.

Voici un exemple d'index sur fonction, chose que vous avez probablement faite:

postgres=# EXPLAIN SELECT * FROM test WHERE nom = 'tata';
                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Index Only Scan using idx_test_nom on test  (cost=0.00..4.30 rows=1 width=5)
   Index Cond: (nom = 'tata'::text)
(2 lignes)

postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE nom = 'tata';
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using idx_test_nom on test  (cost=0.00..8.45 rows=9 width=5) (actual time=0.070..0.073 rows=1 loops=1)
   Index Cond: (nom = 'tata'::text)
 Total runtime: 0.135 ms
(3 lignes)

postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE lower(nom) = 'tata';
                                               QUERY PLAN                                               
--------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..5092.17 rows=1311 width=5) (actual time=278.159..278.161 rows=1 loops=1)
   Filter: (lower(nom) = 'tata'::text)
   Rows Removed by Filter: 262144
 Total runtime: 278.215 ms
(4 lignes)

postgres=# CREATE INDEX idx_test_lower_nom ON test (lower(nom));
CREATE INDEX
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE lower(nom) = 'tata';
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on test  (cost=26.44..1261.33 rows=1311 width=5) (actual time=0.272..0.273 rows=1 loops=1)
   Recheck Cond: (lower(nom) = 'tata'::text)
   ->  Bitmap Index Scan on idx_test_lower_nom  (cost=0.00..26.11 rows=1311 width=0) (actual time=0.253..0.253 rows=1 loops=1)
         Index Cond: (lower(nom) = 'tata'::text)
 Total runtime: 0.343 ms
(5 lignes)

Ensuite, pour utiliser LIKE, n'oubliez pas de créer l'index sur fonction avec l'option varchar_pattern_ops:

postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE lower(nom) LIKE 'tat%';
                                               QUERY PLAN                                               
--------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..5092.17 rows=1311 width=5) (actual time=244.566..244.568 rows=1 loops=1)
   Filter: (lower(nom) ~~ 'tat%'::text)
   Rows Removed by Filter: 262144
 Total runtime: 244.620 ms
(4 lignes)

postgres=# DROP INDEX idx_test_lower_nom ;
DROP INDEX
postgres=# CREATE INDEX idx_test_lower_nom ON test (lower(nom) varchar_pattern_ops);
CREATE INDEX
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE lower(nom) LIKE 'tat%';
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on test  (cost=29.72..1264.61 rows=1311 width=5) (actual time=0.262..0.264 rows=1 loops=1)
   Filter: (lower(nom) ~~ 'tat%'::text)
   ->  Bitmap Index Scan on idx_test_lower_nom  (cost=0.00..29.39 rows=1311 width=0) (actual time=0.222..0.222 rows=1 loops=1)
         Index Cond: ((lower(nom) ~>=~ 'tat'::text) AND (lower(nom) ~<~ 'tau'::text))
 Total runtime: 0.335 ms
(5 lignes)

Je vous demandais de faire rpm -ql sur un paquet particulier. Vous saurez donc où se trouve les binaires.

De mémoire, c'est /usr/pgsql-9.1 mais ce n'est pas sûr.

Alors, je reviens avec ça. On avait loosé une conf de VMWare pour l'accès au SAN --> réglé.
Ensuite je n'ai pas suivi, mais il y aussi une histoire avec la version de vmware tools et probablement des pilotes. Là, je ne sais pas en dire plus, n'étant pas en charge de ça (et surtout formateur au moment de la résolution).

Bonjour,

Attention concernant le vocabulaire. En vous connecter avec le user test et en allant voir chez toto,vous vous connectez sur la BASE toto et n'allez pas voir dans le schéma de toto. Une instance Postgres peut héberger plusieurs bases de données - pour preuve, les deux ordres CREATE DATABASE que vous avez passez.
Et pour vous répondre, lorsque vous faites le CREATE DATABASE, Postgres vous place implicitement un ordre "GRANT CONNECT, TEMPORARY ON DATABASE base TO public;" public étant un alias pour dire "tout le monde".
Donc pour interdire à test de se connecter sur la base toto, vous devrez y aller en deux étapes :
- REVOKE CONNECT, TEMPORARY ON DATABASE toto FROM public;
- GRANT CONNECT, TEMPORARY ON DATABASE toto TOTO;

Et contrairement à Oracle (car j'imagine que la confusion vient de là), un utilisateur ne dispose pas d'un schéma particulier qui lui est dédié. A vous de créer les bons schémas dans les bonnes bases. En revanche, chaque base possède un schéma "public" dans lequel tout le monde peut créer des objets.
De la même façon, le schéma public reçoit implicitement un "GRANT ALL ON SCHEMA public TO public;".

On a une nouvelle piste: les VM qui ont maintenant de bonnes perfs sont en RHEL 5. Celles qui posent encore problèmes sont en CentOS 5. De la même façon, les RHEL disposent de moins de RAM que les CentOS. Encore une fois, il nous faut pousser les tests pour avoir une réponse.
Concernant la charge, on est limite, mais pour l'instant on tient encore.

Salut Jean-Paul,

Je referai un retour si j'ai l'occasion de faire ces fameux tests de performances. N'hésitez pas à compléter ou à corriger les infos, je ne prétend pas que c'est la recette miracle. Néanmoins, les accès disques sont maintenant normaux.

A+

Je vois où vous voulez en venir, mais j'ai le sentiment que ce n'est pas la bonne approche.

Voyez d'abord la section 8.5.1 de la doc: http://www.postgresql.org/docs/8.4/stat … etime.html
PostgreSQL devrait décoder de lui même une date de la forme DD/MM/YYYY. Il faudra néanmoins d'assurer que le paramètre datestyle soit positionné à 'iso, dmy' ou 'sql, dmy' (dans le postgresql.conf, ou dans la session avec SET datestyle='sql, dmy';). Vous devriez vous économiser un trigger.

Pour info:
postgres=# CREATE TABLE test (date_referentiel DATE);

postgres=# SHOW datestyle ;
DateStyle
-----------
ISO, DMY
(1 ligne)

postgres=# INSERT INTO test (date_referentiel) VALUES ('21/09/2011');
INSERT 0 1

postgres=# SELECT * FROM test;
date_referentiel
------------------
2011-09-21
(1 ligne)

Bonjour,

Avec la fonction ST_AsText ?

C'était une mauvaise conf de notre part. Voilà.