Re: PostgreSQL 9.5beta - row level security et performances

2015-10-18 19:34 GMT+02:00 Éric de la Musse <eric901(at)pouik(dot)org>:

> Bonjour,
>
> je me permets de vous solliciter sur un problème de perte sensible de
> performance lorsque j'utilise une des nouvelles fonctionnalités de la
> 9.5 (je suis en 9.5beta 1): les "row level security" (j'attendais avec
> impatience cette version pour cette fonctionnalité précisément mais au
> vu des résultats ci-dessous je vais mettre mon chapeau dessus si je
> n'arrive pas à avoir de meilleures performances).
>
> Je synthétise par 2 requêtes puis j'essaie de développer un peu:
>
> 1/ Requête 1 avec les row level security *désactivés* sur les tables:
>
> $ psql... <<EOF
> \timing
> SELECT m.id, j.code, j.libelle, p.number , p.libelle,
> m.date_mouvement , m.mode, m.piece, m.ref, m.libelle, m.montant FROM
> mouvements m LEFT JOIN journaux j ON m.client_code = j.client_code AND
> m.dossier_code = j.dossier_code AND m.journal = j.code LEFT JOIN plans
> p ON m.plan = p.id WHERE m.client_code='DEMO' AND m.dossier_code='DEMO'
> AND m.journal='BQ' AND m.date_mouvement BETWEEN '2015-09-01' AND
> '2015-10-30';
> EOF
> Mot de passe :
> Chronométrage activé.
> id | code | libelle | number | libelle | date_mouvement |
> mode | piece | ref | libelle | montant
>
> ------+------+-----------+--------------+--------------+----------------+------+-------+-----+--------------------------------+-----------
> ...les données....
> (15 lignes)
>
> Temps : 35,026 ms
>
> 2/ Requête 2 avec les row level security *activés* sur les tables:
> ... même chose...
> (15 lignes)
>
> Temps : 2590,951 ms
>
> Soit un rapport de 1 à 74... une paille !
>
> Cette perte de performance n'est pas généralisable à l'ensemble des
> requêtes, loin de là (c'est même la 1ère requête avec laquelle je
> constate ce phénomène mais je suis loin d'avoir fini de développer le
> programme pour lequel j'utilise la fonctionnalité). Par exemple, dans
> la requête ci-dessus si j'enlève le LEFT JOIN sur la table "plans" je
> retrouve des temps plus raisonnables (quoique du simple au double sans
> ou avec les row level security).
>
> Je ne sais pas trop par quel bout prendre le problème pour savoir si
> je peux améliorer la situation. J'ai des doutes par exemple sur les
> polices que je mets en place : ne sont elles pas trop compliquées ? Par
> exemple, si je prends celle de la table "plans" cela donne:
>
> CREATE POLICY plans_policy ON plans FOR ALL TO PUBLIC
> USING(EXISTS(SELECT 1 FROM acces_dossiers ad WHERE ad.client_code =
> plans.client_code AND ad.dossier_code = plans.dossier_code AND ad.actif
> = true AND current_user = role_from_email(ad.user_email)))
> WITH CHECK(EXISTS(SELECT 1 FROM acces_dossiers ad WHERE
> ad.client_code = plans.client_code AND ad.dossier_code =
> plans.dossier_code AND ad.actif = true AND current_user =
> role_from_email(ad.user_email)));
>
> Est ce que je demande trop à cette fonctionnalité ou l'utilise mal ?
>
> Autres observations: l'augmentation des temps semble proportionnel au
> nombre de lignes renvoyé. Ce qui m'apparaît pour le coup "logique".
>
> Voilà si vous avez des idées me permettant d'avancer vers une
> éventuelle résolution du problème. En attendant je vais désactiver
> la fonctionnalité sur les tables concernées car la perte de performances
> est beaucoup trop importante.
>
>
À tout hasard, est-ce que la fonction role_from_email() est déclarée comme
volatile, et si oui est-il possible de la déclarer comme immutable ?

> --
> Éric de la Musse
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>