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

#2 Re : Optimisation » Index GIN et égalité » 27/10/2020 11:42:01

Bonjour,

Il y a quand même toujours quelque chose qui m'échappe avec ce GIN index et le calcul du plan d'exécution :

Là, pour moi tout est normal :

dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1';
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on document  (cost=2530.38..183518.22 rows=50372 width=50)
   Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
   ->  Bitmap Index Scan on ix_ds_document_id_cellar  (cost=0.00..2517.79 rows=50372 width=0)
         Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
 JIT:
   Functions: 4
   Options: Inlining false, Optimization false, Expressions true, Deforming true
(7 rows)

Pourquoi diable l'ajout de "limit 1" le dissuade d'utiliser l'index ? (enfin là encore je pourrais comprendre si on suppose que le like ramène un % de lignes assez élevé...)

dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..61.28 rows=1 width=50)
   ->  Seq Scan on document  (cost=0.00..3086581.90 rows=50372 width=50)
         Filter: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(3 rows)

Mais pourquoi l'ajout d'un joker (peut importe lequel et peut importe sa position)  va à nouveau faire choisir au planner l'usage de l'index ??

dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '%487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Limit  (cost=2051.81..2055.77 rows=1 width=50)
   ->  Bitmap Heap Scan on document  (cost=2051.81..6038.96 rows=1007 width=50)
         Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '%487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
         ->  Bitmap Index Scan on ix_ds_document_id_cellar  (cost=0.00..2051.56 rows=1007 width=0)
               Index Cond: ((extra ->> 'id_cellar'::text) ~~ '%487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(5 rows)

#3 Re : Optimisation » Index GIN et égalité » 26/10/2020 10:18:10

rjuju a écrit :

Pour information j'ai proposé de gérer ce cas pour gin_trgm_ops et gin_trgm_ops et l'idée est plutôt bienvenue : https://www.postgresql.org/message-id/f … .gmail.com .  J'ai également proposé un patch pour ça, avec un peu de chance cela sera intégré dans la version 14 de postgres.


Cool ;-)

Ça évitera probablement quelques "accidents"...

#4 Re : Optimisation » Index GIN et égalité » 23/10/2020 18:22:39

Je suis bien d'accord, mais les rares fois où on a besoin d'une recherche exacte, c'est ballot de faire un table scan alors qu'on a un index qui peut bien accélérer les choses (même si c'est pas aussi bien qu'un B-Tree dans ce cas particulier) ;-)

Mais bon, il suffit de le savoir, et on fait du LIKE 'ABC' au lieu de = 'ABC', c'est juste un peu contre-intuitif.

#5 Re : Optimisation » Index GIN et égalité » 22/10/2020 15:44:29

Merci de la réponse.

Je trouve cela étrange, puisque je ne vois pas bien la différence entre LIKE 'ABC' et = 'ABC' ...

#6 Optimisation » Index GIN et égalité » 22/10/2020 14:52:16

herve.lefebvre
Réponses : 10

Bonjour,

Je suis tombé sur un comportement étrange avec pg 12.4, je ne sais pas bien si cela relève d'un bug de l'optimiseur PG ou bien de quelque chose qui m'échappe...

J'ai une table avec 10 millions de lignes (propre en terme de VACUUM ANALYZE). Elle comporte un champ "EXTRA" de type JSONB dont l'attribut "celex" est indexé en GIN :

 "ix_ds_document_id_celex" gin ((extra ->> 'id_celex'::text) gin_trgm_ops) WHERE (extra ->> 'id_celex'::text) IS NOT NULL

Si je recherche une ligne en faisant une égalité, il fait un full scan de la table, alors que si je fais un LIKE il utilise bien l'index !?

dev=> explain select id from ds.document where extra->>'id_celex' = 'ABC';
                                   QUERY PLAN                                    
---------------------------------------------------------------------------------
 Gather  (cost=1000.00..2682290.02 rows=50435 width=8)
   Workers Planned: 2
   ->  Parallel Seq Scan on document  (cost=0.00..2676246.52 rows=21015 width=8)
         Filter: ((extra ->> 'id_celex'::text) = 'ABC'::text)
 JIT:
   Functions: 4
   Options: Inlining true, Optimization true, Expressions true, Deforming true
(7 rows)

dev=> explain select id from ds.document where extra->>'id_celex' like 'ABC';
                                         QUERY PLAN                                         
--------------------------------------------------------------------------------------------
 Bitmap Heap Scan on document  (cost=634.87..180484.00 rows=50435 width=8)
   Recheck Cond: ((extra ->> 'id_celex'::text) ~~ 'ABC'::text)
   ->  Bitmap Index Scan on ix_ds_document_id_celex  (cost=0.00..622.26 rows=50435 width=0)
         Index Cond: ((extra ->> 'id_celex'::text) ~~ 'ABC'::text)
 JIT:
   Functions: 4
   Options: Inlining false, Optimization false, Expressions true, Deforming true
(7 rows)

J'aimerais bien comprendre....

#7 Re : Général » Upgrade 9.6 vers 11 » 11/12/2018 17:03:30

gleu a écrit :

Dans le cas d'un disque NVMe, il n'y a pas de tête de lecture à déplacer et la différence entre random_page_cost et seq_page_cost est typiquement le coût de ce déplacement. De ce fait, avoir une valeur très proche pour ces deux paramètres est généralement une bonne idée de base.


Ah j'avais pas vu qu'il y avait du NVMe :-p

Mais pour info, sur du Power P9 avec NVMe, j'ai eu un surcoût FIO d'environ 50% sur du random par rapport au sequential. J'ai supposé que le NVMe avait son propre mécanisme de read-ahead...

#8 Re : Général » Upgrade 9.6 vers 11 » 11/12/2018 15:33:33

gleu a écrit :

2. Au niveau PostgreSQL, je baisserais en effet le random_page_cost mais je ne toucherais à aucun autre paramètre.

Je ne suis pas d'accord, il faut que le ratio random_page_cost/seq_page_cost corresponde à la réalité du matériel (à mesurer par exemple avec FIO https://dotlayer.com/how-to-use-fio-to- … -in-linux/ ).

En effet, sans cet ajustement, le planner risque par exemple d'utiliser un index alors qu'un sequential scan aurait été moins coûteux (ou le contraire).

#9 Re : Général » configuration matérielle optimale » 10/12/2018 14:15:24

Si vous mettez différents tablespaces sur différents disques (en particulier s'il y a du HDD et du SDD mixés), bencher les différents disques en lecture séquentielle/aléatoire (IOPS), et adapter en conséquence les options  seq_page_cost/random_page_cost des fifférents tablespace, faute de quoi l'optimiseur peut choisir des plans d'exécution non-optimaux.

#10 Re : Général » problèmes avec execute » 01/12/2018 19:00:09

dverite a écrit :

mais alors sous plpgsql a-t-on la possibilité de faire une indirection ?

Non, plpgsql ne sait pas faire ça, pas plus que sql.
Au mieux, les fonctions telles que row_to_json() permettent de lire des jeux de résultats de manière un peu dynamique du fait du modèle collection/clef/valeur du type json,
Mais pour aller vraiment plus loin il faut passer aux langages où les noms de colonnes ne sont pas des identifiants mais des variables.


Ben soit je ne comprend pas ce qu'il veut faire, soit il peut le faire avec du sql dynamique non ?

aegir=# create table toto(id integer);
CREATE TABLE
aegir=# insert into toto (select generate_series(1,1000));                                                                                  
INSERT 0 1000
aegir=# CREATE OR REPLACE FUNCTION test(text) RETURNS SETOF integer as $$
aegir$# begin return query execute( $1 ); end; $$
aegir-# LANGUAGE plpgsql;
CREATE FUNCTION
aegir=# select * from test('select id from toto limit 5');
 test 
------
    1
    2
    3
    4
    5
(5 rows)

#11 Re : Général » Argument pour choix d'implémentation datawarehouse » 27/11/2018 15:55:52

gleu a écrit :

Il existe à ma connaissance très peu d'instances de PostgreSQL avec des volumétries de ce type (20 To).

Aux pgdays il y a quelques années à Lyon, il y avait eu une présentation d'une équipe qui gérait la cartographie des Pays-Bas ; laquelle était refaite à coups de LIDAR.

C'était 6 To PAR DataSet

https://www.postgresql-sessions.org/_me … s_lyon.pdf

#12 Re : Installation » MAXSTRLEN dans ts_parser » 08/06/2018 08:02:41

rjuju a écrit :

Attention, il s'agit d'octets et non de caractères.  Selon l'encodage et les caractères utilisés, vous pouvez avez bien plus d'un octet par caractère.  Cette constante est également utilisée comme taille maximale de token utilisable dans un tsvector ou un tsquery.


Sinon, je ne sais pas trop ce que donnerait l'utilisation d'un binaire ainsi modifié sur une base de données avec des index déjà créés sur du contenu qui serait alors ignoré.


Ah oui bonne remarque pour la taille en octets.

Autrement, on est bien d'accord, il faut refaire les ts_vector et les index sur la base après ça.

Bon je vais essayer, sur mon P9 de bench.

#13 Installation » MAXSTRLEN dans ts_parser » 07/06/2018 13:00:54

herve.lefebvre
Réponses : 3

Bonjour,

Le ts_parser est par défaut compilé avec :

#define IGNORE_LONGLEXEME  1

(défini dans src/backend/tsearch/ts_parse.c )

ce qui fait que lors de l'appel à to_tsvector() les lexèmes d'une longueur supérieure à MAXSTRLEN sont ignorés.

Ce qui est très bien.

Cependant, dans src/include/tsearch/ts_type.h on a :

#define MAXSTRLEN ( (1<<11) - 1)

soit 2047.

Dans la mesure où en français le mot le plus long est de 26 lettres - et que je ne suis pas certain que dans les autres langues il soit pertinent non plus d'indexer des mots d'une telle longueur - je suis bien tenté de recompiler avec comme modification :

#define MAXSTRLEN ( (1<<6) - 1)

soit 63 lettres.

(ceci afin de me débarrasser de l'indexation de chaînes interminables purement parasites).

Pensez-vous que cela puisse avoir des effets de bord quelque part ?

#14 Re : Général » COLLATE insatisfaisant » 12/01/2018 14:51:16

A vrai dire je m'inquiète moins pour les index qui sont faciles à recréer que pour les effets de bords sur le serveur ( tris dans les script shell etc.) donc je crois qu'effectivement la création d'un fr_PG va s'imposer.

Quoiqu'il en soit, avoir des espaces et des apostrophes ignorés dans les tris alphabétiques, cela me paraît relever du bug dans la distro Linux.

#15 Re : Général » COLLATE insatisfaisant » 12/01/2018 11:24:04

Donc c'est bien lié au fichier /usr/share/i18n/locales/iso14651_t1_common de la distribution Linux. Je mets ici un hack un peu dégueulasse mais qui pourra toujours être utile à ceux qui rencontrent le même problème.
Afin que les espaces et apostrophes en milieu de chaînes soient correctement triés :

1)    Éditer le fichier /usr/share/i18n/locales/iso14651_t1_common

Remplacer la ligne :

<U0020> IGNORE ;IGNORE ;IGNORE;<U0020> # 32 <SP>

Par :

<U0020> <BAS>;<MIN>;IGNORE;<U0020> # 32 <SP>

Et la ligne :

<U0027> > IGNORE ;IGNORE ;IGNORE;<U0027> # 61 '

Par :

<U0027> <BAS>;<MIN>;IGNORE;<U0027> # 61 '


2)    Éditer le fichier /usr/share/i18n/locales/iso14651_t1_common et ajouter un espace après un commentaire. C’est juste pour modifier le hash du fichier.
3)    Régénérer les locales avec la commande « locale-gen » :


herve@herve-VirtualBox:/var/lib/locales/supported.d > sudo locale-gen
Generating locales...
  en_AG.UTF-8... up-to-date
  en_AU.UTF-8... up-to-date
  en_BW.UTF-8... up-to-date
  en_CA.UTF-8... up-to-date
  en_DK.UTF-8... up-to-date
  en_GB.UTF-8... up-to-date
  en_HK.UTF-8... up-to-date
  en_IE.UTF-8... up-to-date
  en_IN.UTF-8... up-to-date
  en_NG.UTF-8... up-to-date
  en_NZ.UTF-8... up-to-date
  en_PH.UTF-8... up-to-date
  en_SG.UTF-8... up-to-date
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... up-to-date
  en_ZM.UTF-8... up-to-date
  en_ZW.UTF-8... up-to-date
  fr_BE.UTF-8... done
  fr_CA.UTF-8... done
  fr_CH.UTF-8... done
  fr_FR.ISO-8859-1... done
  fr_FR.UTF-8... done
  fr_LU.UTF-8... done
Generation complete.

4)    Redémarrer le serveur pgsql :

herve@herve-VirtualBox:/var/lib/locales/supported.d > sudo service postgresql restart
[sudo] password for herve: 
 * Restarting PostgreSQL 9.3 database server                                                                                                                                             [ OK ] 
 * Restarting PostgreSQL 9.5 database server                                                                                                                                             [ OK ]

Maintenant le tri s'effectue comme attendu :

herve=# select '*'||lib||'*' from t1 order by lib collate "fr_FR";
  ?column?   
-------------
*   *
*aba *
*aba ax*
*abaa*
*abab*
*eminem*
*eminence*
*éminence*
*eminences*
*éminences*
*l amour*
*l'amour*
*laamour*
*lamour*
*lzamour*
(15 lignes)

#16 Re : Général » COLLATE insatisfaisant » 12/01/2018 09:53:35

J'ai trouvé un début de réponse ici : https://www.postgresql.org/message-id/t … lcom-lxa05

Je vais creuser.

Si quelqu'un a déjà été confronté au problème je suis toujours preneur.

#17 Général » COLLATE insatisfaisant » 12/01/2018 09:31:59

herve.lefebvre
Réponses : 5

Bonjour,

Je n'arrive pas à faire un simple ORDER BY :-D

Je suis en fr_FR.utf8 :



herve=# select datname,datcollate,datctype from pg_database;
      datname      | datcollate  |  datctype   
-------------------+-------------+-------------
 template1         | fr_FR.UTF-8 | fr_FR.UTF-8
 template0         | fr_FR.UTF-8 | fr_FR.UTF-8
 postgres          | fr_FR.UTF-8 | fr_FR.UTF-8
 herve             | fr_FR.UTF-8 | fr_FR.UTF-8
 MyApp             | fr_FR.UTF-8 | fr_FR.UTF-8
 myapp_development | fr_FR.UTF-8 | fr_FR.UTF-8
 myapp_test        | fr_FR.UTF-8 | fr_FR.UTF-8
(7 lignes)

Mon problème, c'est que lors des tris, les espaces ou apostrophes en milieux de chaînes sont ignorés. Dans l'exemple suivant, je pense que théoriquement "aba ax" devrait être AVANT "abaa" par exemple.

herve=# select '*'||lib||'*' from t1 order by lib;
  ?column?   
-------------
 *   *
 *aba *
 *abaa*
 *aba ax*
 *abab*
 *eminem*
 *eminence*
 *éminence*
 *eminences*
 *éminences*
 *laamour*
 *lamour*
 *l amour*
 *l'amour*
 *lzamour*
(15 lignes)

En utilisant un collate POSIX, les espaces sont bien pris en compte, mais du coup les caractères accentués sont classés en fin d'alphabet :

herve=# select '*'||lib||'*' from t1 order by lib collate "POSIX";
  ?column?   
-------------
 *   *
 *aba *
 *aba ax*
 *abaa*
 *abab*
 *eminem*
 *eminence*
 *eminences*
 *l amour*
 *l'amour*
 *laamour*
 *lamour*
 *lzamour*
 *éminence*
 *éminences*
(15 lignes)

Quelqu'un aurait une idée pour que les espaces / apostrophes en milieu de chaîne soient pris en compte, et les caractères accentués gérés correctement ?

(comportements observés en 9.3 et 9.5, Linux).

#18 Re : PL/Python » Performances Pl/Python » 21/03/2017 15:04:17

Bon ben je vais bencher alors ;-)

L'intérêt comme je le disais, c'est surtout de pouvoir utiliser les nombreuses librairies python, ou avoir une librairie de régles de gestions communes pour l'applicatif et les UDFs. Ca évite par exemple de devoir faire des batches en python avec psychopg2. On peut le faire directement dans une fonction plpython.

#19 PL/Python » Performances Pl/Python » 17/03/2017 18:41:18

herve.lefebvre
Réponses : 2

Bonjour,

Pour un projet, j'ai décidé pour différentes raisons (principalement pour pouvoir utiliser des librairies Python spécifiques) d'utiliser plpython3u pour toutes ou partie des procédures stockées.

J'aimerais savoir si il y a des différences de performances fondamentales entre les 2 au niveau interne du moteur postgres. Par exemple, est-ce que les plans d'exécution seraient conservés en cache uniquement en PlPgsql (auquel cas il serait plus pertinent d'utiliser plpgsql pour les procédures n'effectuant quasiment que des opérations SQL)  ou bien est-ce que le langage utilisé n'a aucune influence ?

Si globalement quelqu'un a des retours d'expérience sur l'utilisation du plpython, je suis preneur.

Merci.

#20 Re : Offres » Loxodata recrute ! » 04/08/2016 22:23:04

Cela semble vraiment intéressant mais comment dire, en terme de géographie c'est aussi un peu vague.

#21 Re : Général » Access*Lock sur table temporaire » 26/07/2016 09:39:38

Bon alors en fait après avoir commencé à récupérer les logs du client, il semble que la table temporaire bloquée n'est finalement pas une table temporaire big_smile

On est finalement dans un problème très classique avec des subqueries codées avec les pieds, qui prennent une plombe à s'exécuter et qui verrouillent une table dont une autre session a besoin. Désolé du dérangement...

#22 Général » Access*Lock sur table temporaire » 25/07/2016 15:13:33

herve.lefebvre
Réponses : 2

Bonjour,

J'ai un problème chez une gros client.

Ils ont un applicatif qui fait du CREATE TEMP TABLE XXX, et qui ensuite a un DROP TABLE XXX qui se retrouve bloqué à cause d'accessexclusive/sharedlock posés sur la table.

Alors il y a forcément un truc qui m'échappe, mais de base je ne vois pas comment c'est possible, puisque la table n'est visible qu'au sein de la session qui l'a créée, donc il n'est théoriquement pas possible qu'elle soit encore verrouillée au moment de l'exécution du DROP. De plus un "select locktype,database,relname,page,tuple,virtualxid,transactionid,classid,objid,objsubid,virtualtransaction,pid,mode,granted from pg_locks a, pg_class b where a.relation=b.oid and relname ilike '%XXX%'" montre bien que c'est le virtualtransaction qui effectue le DROP qui possède les locks sur la table.

Du coup évidemment, nombreuses "orphan temp table" etc.

Si quelqu'un a une idée je suis preneur, parce que ça me laisse perplexe cette histoire.

Vous pensez qu'il y a un moyen que ce verrouillage provienne d'un hotstandby et/ou du mécanisme de réplication ?
Est-ce que un curseur non fermé pourrait laisser traîner des locks et empêcher un DROP par exemple ?

#23 Re : Général » Canceling statement due to conflict WITH recovery » 08/06/2016 12:41:59

Bonjour, et désolé pour cette exhumation...

rjuju a écrit :

vous pouvez activer le paramètre hot_standby_feedback sur le maître.

Ne serait-ce pas plutôt sur le stand-by ?

#24 Publications » Bull annonce bullionDB » 25/02/2014 17:20:39

herve.lefebvre
Réponses : 0

Bonjour,

Si je poste ce message à un endroit inadéquat, veuillez m'excuser.


http://www.wcm.bull.com/internet/pr/new … 39&lang=fr


Intégralement supportée par Bull, bullionDB s'appuie sur des bases de données PostgreSQL, la virtualisation pour la flexibilité, et bullion, le serveur x86 le plus puissant du marché. Bull fournit également un point d'administration unique pour les nouvelles bases créées ou migrées, permettant de proposer une appliance base de données ouverte, clé en main, cloud-ready.

#25 Re : Général » Taille maximale de table ? » 15/11/2013 13:48:00

Merci pour les infos.

Pour la partie TOAST, la limite est de 32To après compression, ou 32To de données brutes avant compression ?

Pied de page des forums

Propulsé par FluxBB